From ghc-devs at haskell.org Sun Mar 1 00:58:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 00:58:14 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.76842612d4a5ade462e2dc9fd8425ed0@haskell.org> #3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by aavogt): Replying to [comment:2 aavogt]: I've since uploaded that QQ to hackage: http://hackage.haskell.org/package/OrPatterns -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 01:37:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 01:37:09 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.7bcb76da4028b30ddb8147104224125d@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: AlessandroVermeulen | Status: new Type: bug | Milestone: 7.12.1 Priority: normal | Version: 7.6.2 Component: Compiler (Type | Keywords: checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Phab:D72 Blocked By: | Related Tickets: #1537, #3613 | -------------------------------------+------------------------------------- Comment (by tomberek): Interested in this. What is the current status? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 06:07:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 06:07:35 -0000 Subject: [GHC] #5063: unix package has untracked dependency on libbsd In-Reply-To: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> References: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> Message-ID: <060.6086987f2fd4d182070abda7fb8e0f37@haskell.org> #5063: unix package has untracked dependency on libbsd -------------------------------------+------------------------------------- Reporter: duncan | Owner: trommler Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by argiopeweb): * cc: core-libraries-committee@? (added) Comment: Passed upstream as https://github.com/haskell/unix/issues/39 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 06:07:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 06:07:54 -0000 Subject: [GHC] #10081: SIGTERM ignored when process has been detached from terminal In-Reply-To: <044.1f8bc4458608289c276bfd2ddfa7272f@haskell.org> References: <044.1f8bc4458608289c276bfd2ddfa7272f@haskell.org> Message-ID: <059.f3a4d78f40c9683dac03f4b7dc0adf94@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by argiopeweb): * cc: core-libraries-committee@? (added) * owner: => ekmett * component: libraries/unix => Core Libraries Comment: Passed upstream as https://github.com/haskell/unix/issues/38 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 06:08:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 06:08:12 -0000 Subject: [GHC] #1487: unix package: test needed for getLoginName In-Reply-To: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> References: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> Message-ID: <062.52a42f2b930030778386f4be2b3e8691@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: ekmett Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8293 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by argiopeweb): * cc: core-libraries-committee@? (added) Comment: Passed upstream as https://github.com/haskell/unix/issues/40 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 15:07:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 15:07:04 -0000 Subject: [GHC] #9795: Debug.Trace.trace is too strict In-Reply-To: <049.4be06b064bc5b595e6d6c5ec99f21602@haskell.org> References: <049.4be06b064bc5b595e6d6c5ec99f21602@haskell.org> Message-ID: <064.341348876a0032d501f7100fe17666cb@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 16:06:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 16:06:50 -0000 Subject: [GHC] #10125: Inproper evaluation of type families Message-ID: <046.0ec11c852a7857538db9b98c2d0b4c3f@haskell.org> #10125: Inproper evaluation of type families -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello! I've got here a small piece of code: {{{#!haskell {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE EmptyDataDecls #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Data.TypeLevel.Bool where import Prelude hiding (Eq) import qualified Prelude as P import Data.Typeable import GHC.TypeLits type family Eq (a :: k) (b :: k) where Eq a a = True Eq a b = False type family If (cond :: Bool) (a :: k) (b :: k) where If True a b = a If False a b = b type family CmpBy (f :: k -> k -> Ordering) (a :: [k]) (b :: [k]) :: Ordering where CmpBy f '[] '[] = EQ CmpBy f (a ': as) (b ': bs) = If (Eq (f a b) EQ) (CmpBy f as bs) (f a b) type family TCompare (a :: [Nat]) (b :: [Nat]) :: Ordering where TCompare '[] '[] = EQ TCompare (a ': as) (b ': bs) = If (Eq a b) (TCompare as bs) (CmpNat a b) type N1 = '[1,2,3,5] type N2 = '[1,2,3,4] main = do print $ (Proxy :: Proxy GT) == (Proxy :: Proxy (TCompare N1 N2)) print $ (Proxy :: Proxy GT) == (Proxy :: Proxy (CmpBy CmpNat N1 N2)) }}} It does NOT compile, while it should. The type-level functions `TCompare` and `CmpBy CmpNat` should work exactly the same way. Right now the former one always returns `EQ`, so the program does not compile with an error: {{{ Bool.hs:49:41: Couldn't match type ?'EQ? with ?'GT? Expected type: Proxy (CmpBy CmpNat N1 N2) Actual type: Proxy 'GT In the second argument of ?(==)?, namely ?(Proxy :: Proxy (CmpBy CmpNat N1 N2))? In the second argument of ?($)?, namely ?(Proxy :: Proxy GT) == (Proxy :: Proxy (CmpBy CmpNat N1 N2))? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 16:07:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 16:07:13 -0000 Subject: [GHC] #10125: Improper evaluation of type families (was: Inproper evaluation of type families) In-Reply-To: <046.0ec11c852a7857538db9b98c2d0b4c3f@haskell.org> References: <046.0ec11c852a7857538db9b98c2d0b4c3f@haskell.org> Message-ID: <061.26ad522c01229623803550f9e595600a@haskell.org> #10125: Improper evaluation of type families -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 16:32:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 16:32:34 -0000 Subject: [GHC] #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself Message-ID: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Test Suite | Operating System: Unknown/Multiple Keywords: test | Type of failure: Other framework makefile | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The GHC test framework assumes that the GHC tools (`ghc-pkg`, `runghc`, `hsc2hs`, etc) are always in the same directory as `ghc` itself While this is probably a safe assumption for "in-tree" compilers, it's not necessarily true for "out-of-tree" compilers. For example, I currently have a thin wrapper of `ghc` in `$HOME/bin/ghc`, which causes the test framework to think that `ghc-pkg` is in `$HOME/bin/ghc-pkg`. I think the restriction should be relaxed as long as `TEST_HC` is not specified and an out-of-tree compiler is used. I suggest changing `testsuite/mk/boilerplate.mk` in the following way: {{{#!patch @@ -56,6 +56,7 @@ TEST_HC := $(STAGE2_GHC) endif else +implicit_compiler = YES IN_TREE_COMPILER = NO TEST_HC := $(shell which ghc) endif @@ -87,24 +88,30 @@ endif # containing spaces BIN_ROOT = $(shell dirname '$(TEST_HC)') +ifeq "$(implicit_compiler)" "YES" +find_tool = $(shell which $(1)) +else +find_tool = $(BIN_ROOT)/$(1) +endif + ifeq "$(GHC_PKG)" "" -GHC_PKG := $(BIN_ROOT)/ghc-pkg +GHC_PKG := $(call find_tool,ghc-pkg) endif ifeq "$(RUNGHC)" "" -RUNGHC := $(BIN_ROOT)/runghc +RUNGHC := $(call find_tool,runghc) endif ifeq "$(HSC2HS)" "" -HSC2HS := $(BIN_ROOT)/hsc2hs +HSC2HS := $(call find_tool,hsc2hs) endif ifeq "$(HP2PS_ABS)" "" -HP2PS_ABS := $(BIN_ROOT)/hp2ps +HP2PS_ABS := $(call find_tool,hp2ps) endif ifeq "$(HPC)" "" -HPC := $(BIN_ROOT)/hpc +HPC := $(call find_tool,hpc) endif $(eval $(call canonicaliseExecutable,TEST_HC)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 18:28:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 18:28:04 -0000 Subject: [GHC] #6079: SEH exception handler not implemented on Win64 In-Reply-To: <044.31bc28f566675131a5a949cb43e64371@haskell.org> References: <044.31bc28f566675131a5a949cb43e64371@haskell.org> Message-ID: <059.21b47a43399b8f5b55ae8ae1994121d2@haskell.org> #6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: derefnull, Related Tickets: | divbyzero | Blocking: | Differential Revisions: Phab:691 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:691 * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Implementation has been mostly rewritten and a more uniform approach used for both x64 and x86. This also allowed the removal of a lot of the build hacks for windows and allows RtsMain to be able to be built with optimizations again. See Phrabricator differential for more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 18:29:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 18:29:18 -0000 Subject: [GHC] #6079: SEH exception handler not implemented on Win64 In-Reply-To: <044.31bc28f566675131a5a949cb43e64371@haskell.org> References: <044.31bc28f566675131a5a949cb43e64371@haskell.org> Message-ID: <059.9a3a371df7c2b22d1499f0e10cdcf8c7@haskell.org> #6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: derefnull, Related Tickets: | divbyzero | Blocking: | Differential Revisions: Phab:D691 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:691 => Phab:D691 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 18:36:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 18:36:38 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.74f3e6f051db309d0a986f300a640af7@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): Hi @rwbarton are you still working on this? If not mind if I take this one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 21:58:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 21:58:29 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.75d180fee9734b7aa0c06ca963f48b11@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------+------------------------------------ Reporter: Ansible | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.1-rc2 Resolution: worksforme | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------ Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Replying to [comment:9 Ansible]: > Installed today on a banana pi running arch. Ghci works there. Maybe its the version of llvm. Please reopen if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 22:03:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 22:03:00 -0000 Subject: [GHC] #9848: List.all does not fuse In-Reply-To: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> References: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> Message-ID: <064.ee515df73beb4d06a2fec556400fd654@haskell.org> #9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * os: Windows => Unknown/Multiple * component: libraries/base => Core Libraries * architecture: x86 => Unknown/Multiple * owner: => ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 22:09:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 22:09:24 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.6864366b6025e971fc1eae06f8029894@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 22:15:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 22:15:19 -0000 Subject: [GHC] #10090: Building ghc with "make -jN" gives different base ABI hashes for N<=8 and N>8 In-Reply-To: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> References: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> Message-ID: <065.68a23072cb91474ac6773b26cc5cf2e7@haskell.org> #10090: Building ghc with "make -jN" gives different base ABI hashes for N<=8 and N>8 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4012 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Replying to [comment:2 int-e]: > ... ghc-7.10 RC2 produced identical ABI hashes in the same scenario. So this appears to have been fixed, at least for the libraries in ghc. @juhpetersen: please reopen if you still have problems with 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 22:19:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 22:19:09 -0000 Subject: [GHC] #10125: Improper evaluation of type families In-Reply-To: <046.0ec11c852a7857538db9b98c2d0b4c3f@haskell.org> References: <046.0ec11c852a7857538db9b98c2d0b4c3f@haskell.org> Message-ID: <061.fd5d71cf19b0002c003e74619cf440c8@haskell.org> #10125: Improper evaluation of type families -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by danilo2): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 1 23:18:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Mar 2015 23:18:46 -0000 Subject: [GHC] #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' (was: Undefined reference to `__sync_fetch_and_xor_8') In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.f71cac2d5a02ce8435d854bbd6902530@haskell.org> #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 00:37:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 00:37:48 -0000 Subject: [GHC] #10123: GHCi won't start in Powershell ISE In-Reply-To: <043.a9eeffae8144a34b6827048ccb008cf5@haskell.org> References: <043.a9eeffae8144a34b6827048ccb008cf5@haskell.org> Message-ID: <058.f43fdf0656a2da7ee64cbbc8188ae7fc@haskell.org> #10123: GHCi won't start in Powershell ISE -------------------------------------+------------------------------------- Reporter: qwfy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: invalid | Keywords: powershell Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: This is not a bug with GHCi, Powershell ISE is not a real console, it's a GUI based emulation which does not support interactive console applications. The same thing will happen if you try to run cmd /K More details: http://blogs.msdn.com/b/powershell/archive/2009/02/04 /console-application-non-support-in-the-ise.aspx -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 00:49:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 00:49:56 -0000 Subject: [GHC] #9887: No message when GCHI reusing compiled code In-Reply-To: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> References: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> Message-ID: <060.6274c2af9e51379ac3a09af4426c02e4@haskell.org> #9887: No message when GCHI reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 06:53:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 06:53:07 -0000 Subject: [GHC] #9673: ghc-7.8.3 fails to build on aarch64 In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.5d6ea8224dc63b976c097fbdb59d97ca@haskell.org> #9673: ghc-7.8.3 fails to build on aarch64 ---------------------------------+-------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+-------------------------------- Comment (by juhpetersen): This also happens with 7.10 RC2 (with Erik's patch https://github.com/ghc/ghc/commit/b9063703301f0d902b4bb2eb28ac27e9bc050ea0 ). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 06:54:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 06:54:37 -0000 Subject: [GHC] #9673: ghc 7.8.4 and 7.10 fail to build on aarch64 (was: ghc-7.8.3 fails to build on aarch64) In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.be5da02abb55e59f85b1933abfd7aca2@haskell.org> #9673: ghc 7.8.4 and 7.10 fail to build on aarch64 ---------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+------------------------------------- Changes (by juhpetersen): * version: 7.8.3 => 7.10.1-rc1 * architecture: arm => aarch64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 09:01:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 09:01:40 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.c680690ddfefb287f524a5520d395209@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: AlessandroVermeulen | Status: new Type: bug | Milestone: 7.12.1 Priority: normal | Version: 7.6.2 Component: Compiler (Type | Keywords: checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Phab:D72 Blocked By: | Related Tickets: #1537, #3613 | -------------------------------------+------------------------------------- Comment (by simonpj): It's stalled. The honest truth is: * No one knows about both GHC and arrows in enough detail to make progress. * I'm willing to support * But it really needs someone who cares about arrows to pay sustained attention. Maybe you? * comment:46 suggests the next steps Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 09:13:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 09:13:33 -0000 Subject: [GHC] #10127: There is no ghc-7.8.4 for 32 bit Windows Message-ID: <047.804fe1d7244a5a49e8039cd864eea478@haskell.org> #10127: There is no ghc-7.8.4 for 32 bit Windows -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Windows-32 is no longer listed as a supported platform, nor is there an installer. Is this intentional? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 09:15:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 09:15:52 -0000 Subject: [GHC] #10099: cabal install broken with ghc 7.10.1-rc2 In-Reply-To: <047.602c37795a358463eb57e7ffa8e992ef@haskell.org> References: <047.602c37795a358463eb57e7ffa8e992ef@haskell.org> Message-ID: <062.32c5620988336c39cf46fc32db63db48@haskell.org> #10099: cabal install broken with ghc 7.10.1-rc2 -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Package system | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): I just installed GHC 7.10-RC2 on another machine and I have the same problem. This time I installed pre-built binaries (ghc-7.10.0.20150123-x86_64-unknown-linux-deb7.tar.bz2) using latest cabal: {{{ $ cabal --version cabal-install version 1.22.0.1 using version 1.22.1.0 of the Cabal library $ cabal install primitive Resolving dependencies... Downloading primitive-0.5.4.0... Configuring primitive-0.5.4.0... cabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 09:38:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 09:38:43 -0000 Subject: [GHC] #10127: There is no ghc-7.8.4 for 32 bit Windows In-Reply-To: <047.804fe1d7244a5a49e8039cd864eea478@haskell.org> References: <047.804fe1d7244a5a49e8039cd864eea478@haskell.org> Message-ID: <062.8a686f727bab3c57be069d221a2f163a@haskell.org> #10127: There is no ghc-7.8.4 for 32 bit Windows -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 09:44:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 09:44:29 -0000 Subject: [GHC] #10128: Data.List.transpose needs more docs Message-ID: <046.278998fc9f3fb8250696da3cd44346be@haskell.org> #10128: Data.List.transpose needs more docs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.4 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- as mentioned by Doug McIlroy on haskell-prime. My preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs: > The transpose function transposes the rows and columns of its argument. For example, > > {{{ > transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]] > }}} > > If some of the rows are shorter than the following rows, their elements are skipped: > > {{{ > transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]] > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 09:54:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 09:54:00 -0000 Subject: [GHC] #10128: Data.List.transpose needs more docs In-Reply-To: <046.278998fc9f3fb8250696da3cd44346be@haskell.org> References: <046.278998fc9f3fb8250696da3cd44346be@haskell.org> Message-ID: <061.5bd95cbfbb55f9b039e92c70e8651d06@haskell.org> #10128: Data.List.transpose needs more docs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"c5977c2e2951e9e346a8f4990d5a6bbdbf9cee0b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c5977c2e2951e9e346a8f4990d5a6bbdbf9cee0b" Extend the docs for Data.List.transpose by giving a sufficient general example to explain what happens when the rows are not of the same lengths. Thanks to Doug McIlroy for the suggestoin. Fixes #10128. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 09:54:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 09:54:12 -0000 Subject: [GHC] #10128: Data.List.transpose needs more docs In-Reply-To: <046.278998fc9f3fb8250696da3cd44346be@haskell.org> References: <046.278998fc9f3fb8250696da3cd44346be@haskell.org> Message-ID: <061.383db35401adda2671fe5cce784ee5f8@haskell.org> #10128: Data.List.transpose needs more docs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 12:33:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 12:33:32 -0000 Subject: [GHC] #8780: abs for IEEE floating point is slightly wrong. In-Reply-To: <047.7d758a25f9194c7d9c9382206575054a@haskell.org> References: <047.7d758a25f9194c7d9c9382206575054a@haskell.org> Message-ID: <062.c1b09b4e1cab4be77198db59fc9fc684@haskell.org> #8780: abs for IEEE floating point is slightly wrong. -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: Component: Compiler | Version: 7.6.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 Revisions: -------------------------------------+------------------------------------- Comment (by augustss): It seems the printing of -0 has changed. Here's my session {{{ $ ghci GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let x = -0 Prelude> x 0 Prelude> isNegativeZero x True Prelude> isNegativeZero (abs x) True Prelude> isNegativeZero (signum x) False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 12:37:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 12:37:24 -0000 Subject: [GHC] #9328: MINIMAL pragma should supprt negation In-Reply-To: <047.2b12e5ee74ebfc9850e94c944d8e3a10@haskell.org> References: <047.2b12e5ee74ebfc9850e94c944d8e3a10@haskell.org> Message-ID: <062.aaf7c6edd5090dec4b03732847bc9d25@haskell.org> #9328: MINIMAL pragma should supprt negation -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by augustss): Yes, you could say that. Implementing nothing is `MINIMAL`, but if you implement `to` you must also implement `from` (and v.v.). But I think it's a natural extension of the `MINIMAL` pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 12:38:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 12:38:49 -0000 Subject: [GHC] #10025: Tracker: "My Tickets" does not work In-Reply-To: <048.640c096e55aadc51bd5349a38c756f3a@haskell.org> References: <048.640c096e55aadc51bd5349a38c756f3a@haskell.org> Message-ID: <063.e7712c51731d0900519222eff1d18318@haskell.org> #10025: Tracker: "My Tickets" does not work -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: worksforme | Keywords: trac my Operating System: Unknown/Multiple | tickets filter Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: The link you're looking for is called [https://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=new&status=patch&order=priority&reporter=$USER tickets I created]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 12:48:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 12:48:18 -0000 Subject: [GHC] #9228: Internal compiler error with -O1 and -O2 In-Reply-To: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> References: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> Message-ID: <062.1cea1780aae3abd9ecc7919455635fdb@haskell.org> #9228: Internal compiler error with -O1 and -O2 -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8892 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by augustss): I will try 7.8.4 when it's available for Win32. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 12:54:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 12:54:00 -0000 Subject: [GHC] #10024: This bug tracker: Can not create filter `x contains y && x contains z` In-Reply-To: <048.3541aa422624d97a483d8bb4b09c8824@haskell.org> References: <048.3541aa422624d97a483d8bb4b09c8824@haskell.org> Message-ID: <063.eb06a4b048d136fa07bf82ed4e2bb6a5@haskell.org> #10024: This bug tracker: Can not create filter `x contains y && x contains z` -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: wontfix | Keywords: trac Operating System: Unknown/Multiple | filter and Type of failure: None/Unknown | Architecture: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: You're right. This is a bug in Trac though; not too much we can do about it. You could try using a regular search engine to find tickets, see BrowserTips. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 12:55:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 12:55:57 -0000 Subject: [GHC] #10022: Clean up GHC.RTS.Flags In-Reply-To: <052.5f42b7b89367d2d1404df9b2172515f5@haskell.org> References: <052.5f42b7b89367d2d1404df9b2172515f5@haskell.org> Message-ID: <067.a500f5a5611d67bbe9ec5c539a5b7e68@haskell.org> #10022: Clean up GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9970 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * owner: => ekmett * component: libraries/base => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 13:10:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 13:10:01 -0000 Subject: [GHC] #10005: Operations on string literals won't be inlined In-Reply-To: <048.79330f90aa6689947b213892c4dfd806@haskell.org> References: <048.79330f90aa6689947b213892c4dfd806@haskell.org> Message-ID: <063.14af954873c75186959a279511e1b54a@haskell.org> #10005: Operations on string literals won't be inlined -------------------------------------+------------------------------------- Reporter: fread2281 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: Compile-time performance bug => Runtime performance bug Comment: I believe we use the term `compile-time performance bugs` for the performance of ghc itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 13:19:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 13:19:58 -0000 Subject: [GHC] #10125: Improper evaluation of type families In-Reply-To: <046.0ec11c852a7857538db9b98c2d0b4c3f@haskell.org> References: <046.0ec11c852a7857538db9b98c2d0b4c3f@haskell.org> Message-ID: <061.bb0d17d3f53d1508eac28ea0a50450b3@haskell.org> #10125: Improper evaluation of type families -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: It's a bug in GHC 7.8. The program should be rejected because you have an un-saturated application of `CmpNat` on the last line. I'm afraid that GHC's type inference machinery is only capable of dealing with ''saturated'' applications of type families. Sorry. HEAD and 7.10 reject it with a decent message. I'll close as invalid because GHC doesn't claim to support it. Many people would like to do higher order type-family programming in this way, but it's an open question how to do so with predicable type inference. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 13:27:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 13:27:00 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.f14e03d1cd6488604a61aa0dc0ac3592@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): What did you mean by "a nice string of logical operations with a couple of branches"? What code do you want from this case expression? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 13:30:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 13:30:32 -0000 Subject: [GHC] #10120: Unnecessary code duplication from case analysis In-Reply-To: <046.10c61b673d034de53b4da023888f711a@haskell.org> References: <046.10c61b673d034de53b4da023888f711a@haskell.org> Message-ID: <061.9b26488c21007620ac715a4ee368c129@haskell.org> #10120: Unnecessary code duplication from case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I don't yet understand #10124, but I've left a comment there. Meanwhile, what remains of this ticket? What do you expect/want GHC to do, under what circumstances? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 13:42:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 13:42:02 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.ae24e41998f3d019bf1fb56b624f1e54@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I would hope that the example above would get lowered to something like the following, {{{#!hs let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9 `orI#` a ==# 11 `orI#` a ==# 19 case p of 1 -> do_something 0 -> do_something_else }}} The idea is that I'd want to avoid emitting branches in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 13:42:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 13:42:54 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.22247fffc5011833e33a58feffcb5596@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: jlengyel Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9994 | Blocking: | Differential Revisions: Phab:D559 -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9994 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 13:44:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 13:44:37 -0000 Subject: [GHC] #9994: Provide option to show current module in ghci prompt without listing imported modules. In-Reply-To: <046.e91d33e47164959a7e2636f93ef934a2@haskell.org> References: <046.e91d33e47164959a7e2636f93ef934a2@haskell.org> Message-ID: <061.37731c6337195b58470480a1a818f796@haskell.org> #9994: Provide option to show current module in ghci prompt without listing imported modules. -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #5850 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #5850 Comment: I think #5850, and the accompanied patch, will allow you to do what you want. Please reopen this ticket if it does not suit your needs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 13:52:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 13:52:18 -0000 Subject: [GHC] #9979: Performance regression GHC 7.8.4 to GHC HEAD In-Reply-To: <044.73ef7dd92c5e21de402bf2a850f099ad@haskell.org> References: <044.73ef7dd92c5e21de402bf2a850f099ad@haskell.org> Message-ID: <059.fd67cb7955e5f14fa25313032da50523@haskell.org> #9979: Performance regression GHC 7.8.4 to GHC HEAD -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 13:56:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 13:56:07 -0000 Subject: [GHC] #8082: Ordering of assembly blocks affects performance In-Reply-To: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> References: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> Message-ID: <063.aabb7d315eb25970d01272394b8b1ca5@haskell.org> #8082: Ordering of assembly blocks affects performance -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 14:04:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 14:04:40 -0000 Subject: [GHC] #9962: time: Show instance for UTCTime is orphan In-Reply-To: <050.e9740b749b32fc8ba700af3893db63f0@haskell.org> References: <050.e9740b749b32fc8ba700af3893db63f0@haskell.org> Message-ID: <065.85807d220ea524d06af9987b6ff8f3f0@haskell.org> #9962: time: Show instance for UTCTime is orphan -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries | Version: 7.8.4 (other) | Keywords: Resolution: duplicate | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: The bugtracker for `time` is over at github. I filed your bug as https://github.com/haskell/time/issues/25 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 14:10:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 14:10:03 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.a66496d0aa424b9f6724ec498b6dc5af@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, #9661 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * related: #6135 => #6135, #9661 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 14:15:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 14:15:09 -0000 Subject: [GHC] #605: Optimisation: strict enumerations In-Reply-To: <047.930f12dd9816334e7bac59b319734f38@haskell.org> References: <047.930f12dd9816334e7bac59b319734f38@haskell.org> Message-ID: <062.6a3d25d79bffd9c8677ffece06620416@haskell.org> #605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? 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 Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) Old description: > Strict enumeration types should be implemented by Int#, both in the > strictness analyser and for constructor fields annotated with {-# UNPACK > #-}. New description: Strict enumeration types should be implemented by `Int#`, both in the strictness analyser and for constructor fields annotated with `{-# UNPACK #-}`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 14:49:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 14:49:18 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.97113c51c9c44388a3c7101f84ebf0fd@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, #9661 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ah, I see. So maybe you want a rule like this: {{{ isTrue# a || isTrue# b = isTrue# (a `orI#` b) }}} NB that the `(==)` method for `Int` says {{{ (I# x) `eqInt` (I# y) = isTrue# (x ==# y) }}} You'd have delay inlining `(||)` a bit, but you could do that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 15:06:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 15:06:57 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.c93d46ffa6d110083819904ae5271a7c@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I started looking at this over the weekend and have started putting together a [[https://ghc.haskell.org/trac/ghc/wiki/RuleContexts|Wiki page]] describing the of Simon's proposal implementation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 15:07:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 15:07:07 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.a9b008acf3c7b42578879c8c585c0104@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 15:08:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 15:08:21 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.99f40582958117822b0224fc68cb0537@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, #9661 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Would could go further and expect {{{ f = \ a_s3EH -> case a_s3EH of _ { I# ds_s3EJ -> case ds_s3EJ of _ { __DEFAULT -> x; 1 -> y; 5 -> y; 8 -> y; 9 -> y; 11 -> y; 19 -> y } } }}} to be replaced by {{{ f = \ a_s3EH -> case a_s3EH of _ { I# ds_s3EJ -> let p! = some_branchless_formula_involving ds_s3EJ case p of _ { __DEFAULT -> x; 1 -> y; } } }}} where `some_branchless_formula_involving` could be any expression that is `1` for `1,5,8,9,11,19` ? whether it is a disjunction of equalities or some fancy bit-fiddling magic. Even more general, how about turning {{{ f = \ a_s3EH -> case a_s3EH of _ { I# ds_s3EJ -> case ds_s3EJ of _ { __DEFAULT -> x; 1 -> y; 5 -> y; 8 -> z; 9 -> y; 11 -> z; 19 -> z } } }}} into {{{ f = \ a_s3EH -> case a_s3EH of _ { I# ds_s3EJ -> let p! = some_branchless_formula_involving ds_s3EJ case p of _ { __DEFAULT -> x; 1 -> y; 2 -> z; } } }}} This would generate one branch per unique right-hand-side of a `->`, instead of one branch per literal matched against. Not sure if Core is the right place for this, though ? it feels more like instruction selection in the code generator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 15:18:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 15:18:15 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.9f3502de02567fd7c86988328cfdb99d@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, #9661 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Well Joachim's stuff depends on spotting common RHSs. I'd rather avoid producing them in the first place. But one could imagine doing both. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 15:30:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 15:30:54 -0000 Subject: [GHC] #10021: Add "Error:" prefix for compile-time error messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.4d673ce5a8288fe73f0c59d1e7776c00@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: k-bx Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): > I wrote two scripts to help me working on this issue. First is turtle- replace-stdout.hs, second is turtle-review.hs. Here they are: https://gist.github.com/k-bx/fe7027c919980eb9b7f0 I haven't look at your script in detail, but are you aware of [Building/RunningTests/Updating make accept]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 15:36:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 15:36:26 -0000 Subject: [GHC] #10021: Add "Error:" prefix for compile-time error messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.8d00c67cf5670310e34b6d775a6ebf4b@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: k-bx Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by k-bx): @thomie thanks, haven't been aware of it at all. Will check it out! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 15:50:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 15:50:13 -0000 Subject: [GHC] #10021: Add "Error:" prefix for compile-time error messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.da7f7ab37ffd9cfacb2dd6527de664d4@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: k-bx Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): If you're going to run that on the full testsuite, make sure you install these [Building/RunningTests/Running#AdditionalPackages packages] with the inplace compiler. Otherwise some tests get skipped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:01:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:01:32 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.5a594775d3e4aa57a11c8f8f35bcd807@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, #9661 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): nomeata, indeed LLVM transforms the C analogue to the example given here into only 9 instructions. I'd agree that it seems better to avoid breaking up the case expression to begin with. This weekend I focused on giving the user the ability to write the branchless implementation explicitly by fixing #9661. It would be nice to have a story for how we could transform cases into branch-less form without user intervention, although I'm not sure how to know when this transform will pay off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:03:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:03:47 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.6ece87c6a9b5711c9c7c8ec02163c6ac@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: jlengyel Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9994 | Blocking: | Differential Revisions: Phab:D623 -------------------------------------+------------------------------------- Changes (by thomie): * differential: Phab:D559 => Phab:D623 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:22:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:22:33 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.c298599d8736b38f844da0262e92fa54@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, #9661 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > I'd agree that it seems better to avoid breaking up the case expression to begin with. Not sure if that helps, after all, we want to have good code even when the user writes a case statement to begin with: {{{ myIsSpace ' ' = True myIsSpace '\n' = True myIsSpace '\t' = True myIsSpace _ = False }}} I would expect the compiler to (try to) create optimal code from this specification, whether it?s a linear list of condition, an if-then-else- tree or a jump table. I looked at the CG, which even has a pass to unify the common branches, but we need CMM first, so we have to generate some assembly. We currently unconditionally generate an if-then-else tree there, so it is hard to rewrite that into something smarter. Maybe the way forward would be to implement this todo from 11 years ago: {{{ emitCmmLitSwitch :: CmmExpr -- Tag to switch on -> [(Literal, CmmAGraphScoped)] -- Tagged branches -> CmmAGraphScoped -- Default branch (always) -> FCode () -- Emit the code -- Used for general literals, whose size might not be a word, -- where there is always a default case, and where we don't know -- the range of values for certain. For simplicity we always generate a tree. -- -- ToDo: for integers we could do better here, perhaps by generalising -- mk_switch and using that. --SDM 15/09/2004 }}} For `emitCmmSwitch` there is already a case that generates a `CmmSwitch` statement, used when compiling to C. So we might want to try to create a `switch` statement also in `emitCmmLitSwitch` when compiling via LLVM, to leave it to the compiler. If we emit a switch statement in `emitCmmLitSwitch` unconditionally, then we can run the common block transformation first, and later, in a separate step replace the `CmmSwitch` by a tree of if-then-else statements, or by some branchless code, or whatever looks best by then. For LLVM, we might simply leave it as a switch statement. In order to do so, the type of `CmmSwitch` would have to support sparse switch statements better ? it currently takes a `[Maybe Label]`. (Disclaimer: I don?t know much about code generation. If I?m not helpful here, just tell me :-)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:32:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:32:09 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.c58e2afdc676ef641e998927be301808@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, #9661 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for doing both! * Try to avoid duplication in the first place (comment:6) * Recover sharing even if duplication happens, or the programmer wrote it (comment:10) Re comment:10, one could do it in Cmm, but I suspect it'd be better done in Core. Could be a variant of `Note [Combine identical alternatives]` in `SimplUtils`. Over to you, Ben. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:35:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:35:10 -0000 Subject: [GHC] #9229: Compiler memory use regression In-Reply-To: <047.2dfbe078c69c15d5f9a03a8fcfb51c79@haskell.org> References: <047.2dfbe078c69c15d5f9a03a8fcfb51c79@haskell.org> Message-ID: <062.708651c8772e8952ae203e38c0d57251@haskell.org> #9229: Compiler memory use regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8852, #8980, | Differential Revisions: #8941, 8960, #7898, #7068, #7944, | #5550, #8836 | -------------------------------------+------------------------------------- Comment (by augustss): I will test it when there's a win-32 ghc-7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:39:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:39:33 -0000 Subject: [GHC] #10103: Outdated comment (or bug?) in `types/TyCon.hs` In-Reply-To: <045.91b7f7fba8a388fdcef9bd508a30b4ac@haskell.org> References: <045.91b7f7fba8a388fdcef9bd508a30b4ac@haskell.org> Message-ID: <060.03689016da957bc759b1f08cf46eb3b9@haskell.org> #10103: Outdated comment (or bug?) in `types/TyCon.hs` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9b3239f81261f05ee3285c1b9dcbe113635145ef/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9b3239f81261f05ee3285c1b9dcbe113635145ef" Improve comments on coreView/tcView, and combine coreExpandTyCon/tcExpandTyCon This is minor stuff triggered by Trac #10103. * Fix outdated comments on tcView/coreView (we should really combine them with a new name, but I'll leave that slightly-disruptive change for now) * Combine tcExpandTyCon_maybe and coreExpandTyCon_maybe (which were identical) into expandSynTyCon_maybe * A few more comment fixups }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:39:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:39:33 -0000 Subject: [GHC] #10122: PolyKinds: inferred type not as polymorphic as possible In-Reply-To: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> References: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> Message-ID: <060.c7a4072baf0cb4e10d56bcfc20d00e57@haskell.org> #10122: PolyKinds: inferred type not as polymorphic as possible -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"cabe174877d0c31535e224d69bd78434b2d28651/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cabe174877d0c31535e224d69bd78434b2d28651" Two kind-polymorphism fixes (Trac #10122) * The original fix was to improve the documentation, in line with the suggestions on Trac #10122 * But in doing so I realised that the kind generalisation in TcRnDriver.tcRnType was completely wrong. So I fixed that and updated Note [Kind-generalise in tcRnType] to explain. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:39:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:39:33 -0000 Subject: [GHC] #10112: Desugaring of do-syntax intros unification var with -XRebindableSyntax In-Reply-To: <048.4d43585c73cf5632373b4b1e6f28bd29@haskell.org> References: <048.4d43585c73cf5632373b4b1e6f28bd29@haskell.org> Message-ID: <063.596b9bd76280d6b94d7fb27c62d862ec@haskell.org> #10112: Desugaring of do-syntax intros unification var with -XRebindableSyntax -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | rebundable/T10112 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"104c0ad53d4d5b6ea5ee67e04eb7943f5f0d4899/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="104c0ad53d4d5b6ea5ee67e04eb7943f5f0d4899" Test Trac #10112 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:39:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:39:33 -0000 Subject: [GHC] #10105: ghc panic Simplifier ticks exhausted when trying UnfoldingDone x_alB In-Reply-To: <050.e25d389a8920cf1d1cafbe416375e037@haskell.org> References: <050.e25d389a8920cf1d1cafbe416375e037@haskell.org> Message-ID: <065.2b0bb93375488a08134115243c104f48@haskell.org> #10105: ghc panic Simplifier ticks exhausted when trying UnfoldingDone x_alB -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d2e6a3b5edd687f2a384cd6671a519e222f664b8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d2e6a3b5edd687f2a384cd6671a519e222f664b8" Improve documentation of infinite inlining bug This fixes the documentation suggestion in Trac #10105 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:42:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:42:11 -0000 Subject: [GHC] #10103: Outdated comment (or bug?) in `types/TyCon.hs` In-Reply-To: <045.91b7f7fba8a388fdcef9bd508a30b4ac@haskell.org> References: <045.91b7f7fba8a388fdcef9bd508a30b4ac@haskell.org> Message-ID: <060.b1632d8ee730fcb1b5c47da19d7d109c@haskell.org> #10103: Outdated comment (or bug?) in `types/TyCon.hs` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I've fixed both, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:43:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:43:30 -0000 Subject: [GHC] #10112: Desugaring of do-syntax intros unification var with -XRebindableSyntax In-Reply-To: <048.4d43585c73cf5632373b4b1e6f28bd29@haskell.org> References: <048.4d43585c73cf5632373b4b1e6f28bd29@haskell.org> Message-ID: <063.41b80ca1e6fd804130f26ddb572e153d@haskell.org> #10112: Desugaring of do-syntax intros unification var with -XRebindableSyntax -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | rebundable/T10112 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Regression test added -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 16:44:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 16:44:14 -0000 Subject: [GHC] #10122: PolyKinds: inferred type not as polymorphic as possible In-Reply-To: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> References: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> Message-ID: <060.c9b7c83bd424efb950ecfe90c1d429d7@haskell.org> #10122: PolyKinds: inferred type not as polymorphic as possible -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | ghci/scripts/T10122 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => ghci/scripts/T10122 Comment: Good points -- and an underlying bug fixed too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 17:15:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 17:15:55 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.57bbe84411451b20a8931508c9b7f5b7@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D669 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5692643c9d17e746327588cd6157a923642b7975/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5692643c9d17e746327588cd6157a923642b7975" Show record construction/update without parens Summary: The 2010 report mentions: "The result of `show` is a syntactically correct Haskell expression ... Parenthesis are only added where needed, //ignoring associativity//". Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D669 GHC Trac Issues: #2530 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 17:15:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 17:15:55 -0000 Subject: [GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 In-Reply-To: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> References: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> Message-ID: <058.bcf5b9ef2e7ca7ca4f6881b85a452864@haskell.org> #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: aclocal.m4 Operating System: Unknown/Multiple | find perm Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"1dfab7a8ace5f09f00f8fb695932b4324e88b822/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1dfab7a8ace5f09f00f8fb695932b4324e88b822" Fix detection of llvm-x.x Summary: Four bug fixes and a little refactoring. * `find -perm \mode` should be `find -perm /mode` (#9697) * `find -regex '$3' should be `find -regex "$3"` (#7661) From `man sh` on my system (Ubuntu 14.04): "Enclosing characters in single quotes preserves the literal meaning of all the characters ..." * LlcCmd and OptCmd should be passed to ghc, using `-pgmlo` and `-pgmlc`, for detection of #9439. * -pgmlo and -pgmlc were undocumented because of an xml tag misplacement. Test Plan: The aclocal.m4 macro has seen about 10 iterations since its inception. Without a testsuite, I can't guarantee this version is bug free either. It's all pretty frustrating. Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D683 GHC Trac Issues: #9697, #7661, #9439 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 17:15:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 17:15:55 -0000 Subject: [GHC] #7661: GHC build system does not detect opt-3.0 and friends In-Reply-To: <049.92ff62a2eb3581afbb83972e4a1c5825@haskell.org> References: <049.92ff62a2eb3581afbb83972e4a1c5825@haskell.org> Message-ID: <064.72508bb2f427e4903a62e2187694349c@haskell.org> #7661: GHC build system does not detect opt-3.0 and friends ----------------------------------------+---------------------------------- Reporter: singpolyma | Owner: dterei Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"1dfab7a8ace5f09f00f8fb695932b4324e88b822/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1dfab7a8ace5f09f00f8fb695932b4324e88b822" Fix detection of llvm-x.x Summary: Four bug fixes and a little refactoring. * `find -perm \mode` should be `find -perm /mode` (#9697) * `find -regex '$3' should be `find -regex "$3"` (#7661) From `man sh` on my system (Ubuntu 14.04): "Enclosing characters in single quotes preserves the literal meaning of all the characters ..." * LlcCmd and OptCmd should be passed to ghc, using `-pgmlo` and `-pgmlc`, for detection of #9439. * -pgmlo and -pgmlc were undocumented because of an xml tag misplacement. Test Plan: The aclocal.m4 macro has seen about 10 iterations since its inception. Without a testsuite, I can't guarantee this version is bug free either. It's all pretty frustrating. Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D683 GHC Trac Issues: #9697, #7661, #9439 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 17:15:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 17:15:55 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.2903afc1a3abaae25d32df67216e6a11@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.4 Component: Compiler (LLVM) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 9268 | Differential Revisions: Phab:D150 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"1dfab7a8ace5f09f00f8fb695932b4324e88b822/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1dfab7a8ace5f09f00f8fb695932b4324e88b822" Fix detection of llvm-x.x Summary: Four bug fixes and a little refactoring. * `find -perm \mode` should be `find -perm /mode` (#9697) * `find -regex '$3' should be `find -regex "$3"` (#7661) From `man sh` on my system (Ubuntu 14.04): "Enclosing characters in single quotes preserves the literal meaning of all the characters ..." * LlcCmd and OptCmd should be passed to ghc, using `-pgmlo` and `-pgmlc`, for detection of #9439. * -pgmlo and -pgmlc were undocumented because of an xml tag misplacement. Test Plan: The aclocal.m4 macro has seen about 10 iterations since its inception. Without a testsuite, I can't guarantee this version is bug free either. It's all pretty frustrating. Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D683 GHC Trac Issues: #9697, #7661, #9439 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 18:58:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 18:58:40 -0000 Subject: [GHC] #10129: emitCmmLitSwitch could be better Message-ID: <046.57ebacba96de4a462b110307efef9134@haskell.org> #10129: emitCmmLitSwitch could be better -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is a spin off #10124. While looking at the code generated for {{{ f :: Int -> Bool f a = case a of 1 -> True 2 -> True 3 -> True 4 -> True 8 -> True 9 -> True 11 -> True 19 -> True _ -> False }}} I noticed this Cmm: {{{ c2tI: if (%MO_S_Lt_W64(_s2sJ::I64, 3)) goto c2tw; else goto c2tx; c2tw: if (%MO_S_Lt_W64(_s2sJ::I64, 2)) goto c2tq; else goto c2tr; c2tq: if (_s2sJ::I64 != 1) goto c2tg; else goto c2th; c2tr: if (_s2sJ::I64 != 2) goto c2tg; else goto c2th; }}} Note that when `c2tr` is reached, we know 2 ? _s2sJ < 3, so _s2sJ already is 2, and this check is redundant. `emitCmmLitSwitch` does not take that into account, probably because it also needs to work for floats. I wonder if it isn?t a bit shady to use an if-then-else tree for floats. Maybe for float types, a sequence of equality tests is more suitable. For all other cases, the code generator could make use of "2 ? x < 3 ? x = 2" and skip one check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 19:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 19:08:30 -0000 Subject: [GHC] #10130: Rigid/Skolum produced by unassociated values. Message-ID: <051.9e88e562c161586263e52aa7256005e8@haskell.org> #10130: Rigid/Skolum produced by unassociated values. -------------------------------------+------------------------------------- Reporter: | Owner: dukerutledge | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Linux Keywords: rigid, | Type of failure: Compile-time skolum, | crash existentialquantification, gadts, | Blocked By: nomonolocalbinds | Related Tickets: Architecture: x86_64 | (amd64) | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Here is an in depth example of a possible GHC bug. It is exacerbated by GADTs, but can be fixed with NoMonoLocalBinds. Without GADTs and just leveraging ExistentialQuantification it works fine. We've included a pretty exhaustive set of examples. {{{ {-# LANGUAGE ExistentialQuantification, GADTs #-} {- removing MonoLocalBinds fixes all of these errors {-# LANGUAGE ExistentialQuantification, GADTs, NoMonoLocalBinds #-} -} module PossibleGHCBug where data SumType = SumFoo | SumBar class SomeClass a where someType :: a -> SumType data SomeExistential = forall a. SomeClass a => SomeExistential a noError :: String -> [SomeExistential] -> String noError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" noError2 :: String -> [SomeExistential] -> String noError2 n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c :: SumType -> String c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n noError3 :: String -> [SomeExistential] -> String noError3 n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d :: SomeClass a => a -> String d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n partialTypedError :: String -> [SomeExistential] -> String partialTypedError n st = n ++ concatMap cname st where cname :: SomeExistential -> String cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n fullError :: String -> [SomeExistential] -> String fullError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n justNError :: String -> [SomeExistential] -> String justNError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> n ignoreNError :: String -> [SomeExistential] -> String ignoreNError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> fst ("foo", n) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 19:09:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 19:09:23 -0000 Subject: [GHC] #10130: Rigid/Skolum produced by unassociated values. In-Reply-To: <051.9e88e562c161586263e52aa7256005e8@haskell.org> References: <051.9e88e562c161586263e52aa7256005e8@haskell.org> Message-ID: <066.588162bad50b9f29f68c627466f75c94@haskell.org> #10130: Rigid/Skolum produced by unassociated values. -------------------------------------+------------------------------------- Reporter: dukerutledge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: rigid, Operating System: Linux | skolum, existentialquantification, Type of failure: GHC rejects | gadts, nomonolocalbinds valid program | Architecture: x86_64 Blocked By: | (amd64) Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dukerutledge): * failure: Compile-time crash => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 20:09:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 20:09:23 -0000 Subject: [GHC] #10103: Outdated comment (or bug?) in `types/TyCon.hs` In-Reply-To: <045.91b7f7fba8a388fdcef9bd508a30b4ac@haskell.org> References: <045.91b7f7fba8a388fdcef9bd508a30b4ac@haskell.org> Message-ID: <060.c682456ec01dbc8cfa4ed30e2046ce42@haskell.org> #10103: Outdated comment (or bug?) in `types/TyCon.hs` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 20:22:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 20:22:48 -0000 Subject: [GHC] #10122: PolyKinds: inferred type not as polymorphic as possible In-Reply-To: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> References: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> Message-ID: <060.dc91b80ca56730026a1a157b89a40b72@haskell.org> #10122: PolyKinds: inferred type not as polymorphic as possible -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7688 | ghci/scripts/T10122 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: invalid => * related: => #7688 * milestone: => 7.12.1 Comment: Closing in a second. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 20:23:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 20:23:21 -0000 Subject: [GHC] #10129: emitCmmLitSwitch could be better In-Reply-To: <046.57ebacba96de4a462b110307efef9134@haskell.org> References: <046.57ebacba96de4a462b110307efef9134@haskell.org> Message-ID: <061.3fe0fdc1ff1c7dbd0abf3b2036966caa@haskell.org> #10129: emitCmmLitSwitch could be better -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D693 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D693 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 20:23:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 20:23:33 -0000 Subject: [GHC] #10122: PolyKinds: inferred type not as polymorphic as possible In-Reply-To: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> References: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> Message-ID: <060.ed6e540b8f752b54552b2eae1d87cc51@haskell.org> #10122: PolyKinds: inferred type not as polymorphic as possible -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7688 | ghci/scripts/T10122 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 20:29:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 20:29:51 -0000 Subject: [GHC] #10129: emitCmmLitSwitch could be better In-Reply-To: <046.57ebacba96de4a462b110307efef9134@haskell.org> References: <046.57ebacba96de4a462b110307efef9134@haskell.org> Message-ID: <061.bb4f8f6fd6b417f640855b68b4251d5c@haskell.org> #10129: emitCmmLitSwitch could be better -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Phab:D693 Related Tickets: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 20:49:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 20:49:02 -0000 Subject: [GHC] #9901: Error message: f is applied to two arguments, but its type has only two (sic) In-Reply-To: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> References: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> Message-ID: <060.e77889976ab300fc9c14eeefcc47f023@haskell.org> #9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: duplicate | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9605 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => duplicate Comment: The fix for #9605 will be in 7.10. @zardoz: please reopen if you don't think your issue is fixed in 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 21:16:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 21:16:58 -0000 Subject: [GHC] #10130: Rigid/Skolum produced by unassociated values. In-Reply-To: <051.9e88e562c161586263e52aa7256005e8@haskell.org> References: <051.9e88e562c161586263e52aa7256005e8@haskell.org> Message-ID: <066.67725350e85c9f7d07c011eb7e203cfc@haskell.org> #10130: Rigid/Skolum produced by unassociated values. -------------------------------------+------------------------------------- Reporter: dukerutledge | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: rigid, Operating System: Linux | skolum, existentialquantification, Type of failure: GHC rejects | gadts, nomonolocalbinds valid program | Architecture: x86_64 Blocked By: | (amd64) Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Why do you think it's a bug? It looks as if GHC is behaving exactly as advertised in the [https://wiki.haskell.org/Simonpj/Talk:OutsideIn OutsideIn paper]. Consider {{{ partialTypedError :: String -> [SomeExistential] -> String partialTypedError n st = n ++ concatMap cname st where cname :: SomeExistential -> String cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n }}} We get {{{ T10130.hs:52:39: Couldn't match expected type `a0' with actual type `a' because type variable `a' would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: SomeExistential :: forall a. SomeClass a => a -> SomeExistential, in an equation for `cname' at T10130.hs:52:16-32 Relevant bindings include p :: a (bound at T10130.hs:52:32) d :: a0 -> [Char] (bound at T10130.hs:54:9) }}} And indeed, the pattern `(SomeExistential p)` binds the type variable `a`, which is then unified with the `a0` from the (monomorphic) type of `d`. All this looks dead right to me. I'll close as invalid (i.e. GHC behaving as specified) for now, but please re-open if you disagree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 21:32:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 21:32:52 -0000 Subject: [GHC] #10131: improve error message for build on noexec-mounted device Message-ID: <048.a5bb5888aa48566235342f4aa1be6ede@haskell.org> #10131: improve error message for build on noexec-mounted device -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- i was building (in a sandbox) on a ramdisk that was accidentally mounted with the noexec flag. for example during the install of `vector`, you get an error like Loading package primitive-0.5.4.0 ... : can't load .so/.DLL for: somepath/.cabal-sandbox/lib/x86_64-linux- ghc-7.8.4/primitive-0.5.4.0/libHSprimitive-0.5.4.0-ghc7.8.4.so (somepath /.cabal-sandbox/lib/x86_64-linux- ghc-7.8.4/primitive-0.5.4.0/libHSprimitive-0.5.4.0-ghc7.8.4.so: failed to map segment from shared object) relevant output of `mount`: none on somepath type tmpfs (rw,nosuid,nodev,noexec,relatime,gid=103,user=lspitzner) this is by far no minimal test-case, but i hope my description of the problem is sufficient. if not, i can provide verbose output for my or other test-cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 21:38:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 21:38:24 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.e5710d06a3028df5e860910b99c05bd1@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => infoneeded Comment: hedayaty, just to say that I'm stalled on this, pending comment:4. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 21:49:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 21:49:21 -0000 Subject: [GHC] #10130: Rigid/Skolum produced by unassociated values. In-Reply-To: <051.9e88e562c161586263e52aa7256005e8@haskell.org> References: <051.9e88e562c161586263e52aa7256005e8@haskell.org> Message-ID: <066.c924c12fb69840e0292297ef30af04ef@haskell.org> #10130: Rigid/Skolum produced by unassociated values. -------------------------------------+------------------------------------- Reporter: dukerutledge | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: rigid, Operating System: Linux | skolum, existentialquantification, Type of failure: GHC rejects | gadts, nomonolocalbinds valid program | Architecture: x86_64 Blocked By: | (amd64) Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Ah, yes. I advised this being posted as a bug report, but I somehow forgot that `d` and `c` would be monomorphic here. To the original poster, who may not be aware of the intricacies of !OutsideIn: The extensions `GADTs` and `TypeFamilies` both enable `MonoLocalBinds`, which makes local definitions that refer to a variable in an outer scope (like `n`) be monomorphic. Thus, `d` and `c` are monomorphic, but there is no monomorphic type to assign to them. I agree with Simon that GHC's behavior here is correct. You could, of course, specify `NoMonoLocalBinds`, but this a bad idea: the `MonoLocalBinds` story is necessary to keep sane type inference in the presence of the hypothetical equality conditions that can be introduced by type families and GADTs. The good news is that all can be fixed by using type signatures on local definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 22:11:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 22:11:03 -0000 Subject: [GHC] #10129: emitCmmLitSwitch could be better In-Reply-To: <046.57ebacba96de4a462b110307efef9134@haskell.org> References: <046.57ebacba96de4a462b110307efef9134@haskell.org> Message-ID: <061.4861b83378e1410eab1132af042423cc@haskell.org> #10129: emitCmmLitSwitch could be better -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Phab:D693 Related Tickets: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"c3eee14d31585445d4a7eff5b6c69a815b911059/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c3eee14d31585445d4a7eff5b6c69a815b911059" Improve if-then-else tree for cases on literal values Previously, in the branch of the if-then-else tree, it would emit a final check if the scrut matches the alternative, even if earlier comparisons alread imply this equality. By keeping track of the bounds we can skip this check. Of course this is only sound for integer types. This closes #10129. Differential Revision: https://phabricator.haskell.org/D693 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 22:23:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 22:23:19 -0000 Subject: [GHC] #10129: emitCmmLitSwitch could be better In-Reply-To: <046.57ebacba96de4a462b110307efef9134@haskell.org> References: <046.57ebacba96de4a462b110307efef9134@haskell.org> Message-ID: <061.7d1dce602147a6b2e7999fb3eef5b932@haskell.org> #10129: emitCmmLitSwitch could be better -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (CodeGen) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Phab:D693 Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: This bit is done. It would still be nice to unify `emitCmmLitSwitch` with `emitSwitch`, but maybe some other day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 22:49:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 22:49:50 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.8e5c3b0ecef35c79d21c4783908979ad@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hedayaty): OOps sorry! I missed the notification. I will test it ASAP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 22:59:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 22:59:46 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.ead0893a2525aec42524ab25f3bddf30@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hedayaty): I attached the generated folder. I will try to handcraft a minimal version, reproducing the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 23:34:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 23:34:24 -0000 Subject: [GHC] #9044: createDirectoryIfMissing does not fail on unwritable parent dir In-Reply-To: <045.f049f1f0d4a8564178ae7c5abb8097be@haskell.org> References: <045.f049f1f0d4a8564178ae7c5abb8097be@haskell.org> Message-ID: <060.9e92e7f86ffc661b459acf0faf7d3266@haskell.org> #9044: createDirectoryIfMissing does not fail on unwritable parent dir -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * status: new => closed * resolution: => fixed Comment: Fixed by https://github.com/haskell/directory/commit/1f113935439a381443b945eb5177fb122881f182 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 2 23:38:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Mar 2015 23:38:14 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.54e2d972aac2c96654969209340b8cd5@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: hvr, core-libraries-committee@? (added) Comment: What is the status of this now with Herbert's new `integer-gmp` approach? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 04:16:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 04:16:12 -0000 Subject: [GHC] #8342: System.Directory.getPermissions does not work well on Windows 7 In-Reply-To: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> References: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> Message-ID: <060.e6a1e9ed4f7bfd7df35e8682e8a51938@haskell.org> #8342: System.Directory.getPermissions does not work well on Windows 7 -------------------------------------+------------------------------------- Reporter: freizl | Owner: leroux Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Rufflewind): * status: upstream => closed * resolution: => fixed Comment: Fixed upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 07:47:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 07:47:33 -0000 Subject: [GHC] #10129: emitCmmLitSwitch could be better In-Reply-To: <046.57ebacba96de4a462b110307efef9134@haskell.org> References: <046.57ebacba96de4a462b110307efef9134@haskell.org> Message-ID: <061.821af0e43047f2b36b5a1b2215c608d4@haskell.org> #10129: emitCmmLitSwitch could be better -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (CodeGen) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Phab:D693 Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Regression test? Maybe too awkward... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 08:08:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 08:08:27 -0000 Subject: [GHC] #10129: emitCmmLitSwitch could be better In-Reply-To: <046.57ebacba96de4a462b110307efef9134@haskell.org> References: <046.57ebacba96de4a462b110307efef9134@haskell.org> Message-ID: <061.39881961f3bf5572a311aeedb41869f6@haskell.org> #10129: emitCmmLitSwitch could be better -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (CodeGen) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Phab:D693 Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): I thought about this, but I?m really not sure how to do it. The best thing I could think of would be to grep on the output of -ddump-cmm, but that seems too fragile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 09:44:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 09:44:51 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.940d35c8d0c7c967ba30b158b170345e@haskell.org> #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): I have just (2015/03/03) written a shell script (attached) that tests for binutils support for 64 bit pc-relative relocatons. The test passes on *all* modern linux systems, but fails on Mac OSX (Mavericks) and OpenBSD 5.5 (current is 5.6). The failure is one OpenBSD says: {{{ linkasm.s:3: Error: can not do 8 byte pc-relative relocation }}} OpenBSD has GNU binutils 2.15 but they are unlikely to upgrade to a later version because later versions are under GPLv3 instead of GPLv2. However, they may at some stage switch to some other linker. OSX has the linker from LLVM which theoretically could be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 09:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 09:47:46 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.8f79ba267ab35486914c0613b3b518c3@haskell.org> #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 10:41:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 10:41:31 -0000 Subject: [GHC] #8780: abs for IEEE floating point is slightly wrong. In-Reply-To: <047.7d758a25f9194c7d9c9382206575054a@haskell.org> References: <047.7d758a25f9194c7d9c9382206575054a@haskell.org> Message-ID: <062.8308be7447b48af1da114b481d7ec68a@haskell.org> #8780: abs for IEEE floating point is slightly wrong. -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7858 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => duplicate * related: => #7858 Comment: A fix for both issues will be in 7.10, see #7858. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 10:55:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 10:55:32 -0000 Subject: [GHC] #10132: Inconsistent kind polymorphism for top-level and associated type families Message-ID: <046.686d0ef50515818913143703d40559ce@haskell.org> #10132: Inconsistent kind polymorphism for top-level and associated type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this, with `-XPolyKinds`: {{{ class C a where data D1 a type F1 a data D2 a type F2 a }}} You'd expect `D1` and `D2` to behave exactly the same; and similarly `F1` and `F2`. But they don't: {{{ D1 :: forall k (a:k). k -> * D2 :: * -> * F1 :: forall k (a:k). k -> * F2 :: * -> * }}} This seems odd. Indeed, when I stumbled across it I thought it was a plain bug. But I think there is some justification: * For associated types like `D1`, `F1` we make the class kind-polymorphic by default. And hence the associated types really have to be also. * Should classes be by-default kind-polymorphic? Well, data types are, so probably classes should be too. The types of the methods of the class, or the constructors of the data type, usually give plenty of clues. * For top-level types like `D2`, `F2`, it seems perhaps overkill to make them kind polymorphic by default. The difference is that they have no right hand side to get clues from, so they'll always have kind `k1 -> k2 -> k3` if you go for maximal polymorphism. You can declare the polymorphism with kind signatures. * Why does `F1` return `*`. It could as well be kind-polymorphic in its result. Again I think this is because there cannot be any clue as to its result kind so we default to `*`. Maybe this is all a good choice. The principle seems to be: '''if the declaration has a "right hand side", infer kinds from that; if not, default to `*`'''. But even if that is the right principle, we should articulate it explicitly, in the user manual and a `Note` somewhere. (I reverse-engineered all this when looking at #9999 again, in the new `Typeable` branch.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 10:59:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 10:59:52 -0000 Subject: [GHC] #10132: Inconsistent kind polymorphism for top-level and associated type families In-Reply-To: <046.686d0ef50515818913143703d40559ce@haskell.org> References: <046.686d0ef50515818913143703d40559ce@haskell.org> Message-ID: <061.80f413e167d05d16e9607609acc09c66@haskell.org> #10132: Inconsistent kind polymorphism for top-level and associated type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider this, with `-XPolyKinds`: > {{{ > class C a where > data D1 a > type F1 a > > data D2 a > type F2 a > }}} > You'd expect `D1` and `D2` to behave exactly the same; and similarly `F1` > and `F2`. But they don't: > {{{ > D1 :: forall k (a:k). k -> * > D2 :: * -> * > > F1 :: forall k (a:k). k -> * > F2 :: * -> * > }}} > This seems odd. Indeed, when I stumbled across it I thought it was a > plain bug. But I think there is some justification: > > * For associated types like `D1`, `F1` we make the class kind- > polymorphic by default. And hence the associated types really have to be > also. > > * Should classes be by-default kind-polymorphic? Well, data types are, > so probably classes should be too. The types of the methods of the > class, or the constructors of the data type, usually give plenty of > clues. > > * For top-level types like `D2`, `F2`, it seems perhaps overkill to make > them kind polymorphic by default. The difference is that they have no > right hand side to get clues from, so they'll always have kind `k1 -> k2 > -> k3` if you go for maximal polymorphism. You can declare the > polymorphism with kind signatures. > > * Why does `F1` return `*`. It could as well be kind-polymorphic in its > result. Again I think this is because there cannot be any clue as to its > result kind so we default to `*`. > > Maybe this is all a good choice. The principle seems to be: '''if the > declaration has a "right hand side", infer kinds from that; if not, > default to `*`'''. > > But even if that is the right principle, we should articulate it > explicitly, in the user manual and a `Note` somewhere. > > (I reverse-engineered all this when looking at #9999 again, in the new > `Typeable` branch.) New description: Consider this, with `-XPolyKinds`: {{{ class C a where data D1 a type F1 a data D2 a type F2 a }}} You'd expect `D1` and `D2` to behave exactly the same; and similarly `F1` and `F2`. But they don't: {{{ D1 :: forall k (a:k). k -> * D2 :: * -> * F1 :: forall k (a:k). k -> * F2 :: * -> * }}} This seems odd. Indeed, when I stumbled across it I thought it was a plain bug. But I think there is some justification: * For associated types like `D1`, `F1` we make the class kind-polymorphic by default. And hence the associated types really have to be also. * Should classes be by-default kind-polymorphic? Well, data types are, so probably classes should be too. The types of the methods of the class, or the constructors of the data type, usually give plenty of clues. * For top-level types like `D2`, `F2`, it seems perhaps overkill to make them kind polymorphic by default. The difference is that they have no right hand side to get clues from, so they'll always have kind `k1 -> k2 -> k3` if you go for maximal polymorphism. You can declare the polymorphism with kind signatures. * Why does `F1` return `*`? It could as well be kind-polymorphic in its result. Again I think this is because there cannot be any clue as to its result kind so we default to `*`. Maybe this is all a good choice. The principle seems to be: '''if the declaration has a "right hand side", infer kinds from that; if not, default to `*`'''. But even if that is the right principle, we should articulate it explicitly, in the user manual and a `Note` somewhere. (I reverse-engineered all this when looking at #9999 again, in the new `Typeable` branch.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 12:29:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 12:29:51 -0000 Subject: [GHC] #2986: :info printing instances often isn't wanted In-Reply-To: <043.cc7348275a1e64e6491d1ee94042b0a6@haskell.org> References: <043.cc7348275a1e64e6491d1ee94042b0a6@haskell.org> Message-ID: <058.1efb8e9b0f22568b6740561b752d8c27@haskell.org> #2986: :info printing instances often isn't wanted -------------------------------------+------------------------------------- Reporter: Remi | Owner: Remi Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: :info Operating System: Unknown/Multiple | instances Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #1581 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #1581 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 13:00:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 13:00:34 -0000 Subject: [GHC] #10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x In-Reply-To: <046.8c38a2755dbd0195fbd11b9263841f8b@haskell.org> References: <046.8c38a2755dbd0195fbd11b9263841f8b@haskell.org> Message-ID: <061.8c0a75959110cc99ce613cb69ece238f@haskell.org> #10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x -------------------------------------+------------------------------------- Reporter: kgardas | Owner: hvr Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc1 (other) | Keywords: Resolution: fixed | Architecture: sparc Operating System: Solaris | Test Case: Type of failure: Building GHC | Blocking: failed | Differential Revisions: Phab:D675 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via 8827ade65eee66c42ff6aa11dff20f9b7bece3e2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 13:25:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 13:25:44 -0000 Subject: [GHC] #10104: Show '#' on unboxed literals In-Reply-To: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> References: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> Message-ID: <060.57e2faf8d8a4a2ca30a417879ede7a7b@haskell.org> #10104: Show '#' on unboxed literals -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8274 | deriving/should_run/T10104 | Blocking: | Differential Revisions: Phab:D672 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"89458eba5721de1b6b3378415f26e110bab8cc0f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="89458eba5721de1b6b3378415f26e110bab8cc0f" Pretty-print # on unboxed literals in core Summary: Ticket #10104 dealt with showing the '#'s on types with unboxed fields. This commit pretty prints the '#'s on unboxed literals in core output. Test Plan: simplCore/should_compile/T8274 Reviewers: jstolarek, simonpj, austin Reviewed By: simonpj, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D678 GHC Trac Issues: #8274 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 13:25:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 13:25:44 -0000 Subject: [GHC] #6079: SEH exception handler not implemented on Win64 In-Reply-To: <044.31bc28f566675131a5a949cb43e64371@haskell.org> References: <044.31bc28f566675131a5a949cb43e64371@haskell.org> Message-ID: <059.bc44bf72ce295c25571909dc9204ea15@haskell.org> #6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: derefnull, Related Tickets: | divbyzero | Blocking: | Differential Revisions: Phab:D691 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5200bdeb26c5ec98739b14b10fc8907296bceeb9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5200bdeb26c5ec98739b14b10fc8907296bceeb9" Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64 Summary: On Windows, the default action for things like division by zero and segfaults is to pop up a Dr. Watson error reporting dialog if the exception is unhandled by the user code. This is a pain when we are SSHed into a Windows machine, or when we want to debug a problem with gdb (gdb will get a first and second chance to handle the exception, but if it doesn't the pop-up will show). veh_excn provides two macros, `BEGIN_CATCH` and `END_CATCH`, which will catch such exceptions in the entire process and die by printing a message and calling `stg_exit(1)`. Previously this code was handled using SEH (Structured Exception Handlers) however each compiler and platform have different ways of dealing with SEH. `MSVC` compilers have the keywords `__try`, `__catch` and `__except` to have the compiler generate the appropriate SEH handler code for you. `MinGW` compilers have no such keywords and require you to manually set the SEH Handlers, however because SEH is implemented differently in x86 and x64 the methods to use them in GCC differs. `x86`: SEH is based on the stack, the SEH handlers are available at `FS[0]`. On startup one would only need to add a new handler there. This has a number of issues such as hard to share handlers and it can be exploited. `x64`: In order to fix the issues with the way SEH worked in x86, on x64 SEH handlers are statically compiled and added to the .pdata section by the compiler. Instead of being thread global they can now be Image global since you have to specify the `RVA` of the region of code that the handlers govern. You can on x64 Dynamically allocate SEH handlers, but it seems that (based on experimentation and it's very under-documented) that the dynamic calls cannot override static SEH handlers in the .pdata section. Because of this and because GHC no longer needs to support < windows XP, the better alternative for handling errors would be using the in XP introduced VEH. The bonus is because VEH (Vectored Exception Handler) are a runtime construct the API is the same for both x86 and x64 (note that the Context object does contain CPU specific structures) and the calls are the same cross compilers. Which means this file can be simplified quite a bit. Using VEH also means we don't have to worry about the dynamic code generated by GHCi. Test Plan: Prior to this diff the tests for `derefnull` and `divbyzero` seem to have been disabled for windows. To reproduce the issue on x64: 1) open ghci 2) import GHC.Base 3) run: 1 `divInt` 0 which should lead to ghci crashing an a watson error box displaying. After applying the patch, run: make TEST="derefnull divbyzero" on both x64 and x86 builds of ghc to verify fix. Reviewers: simonmar, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D691 GHC Trac Issues: #6079 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 13:25:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 13:25:44 -0000 Subject: [GHC] #8274: Core pretty-printer doesn't print # on unboxed literals In-Reply-To: <048.0e77035003859b63254a7c6b1235c7cc@haskell.org> References: <048.0e77035003859b63254a7c6b1235c7cc@haskell.org> Message-ID: <063.59f3ffd16a06391b868707d7eba60aec@haskell.org> #8274: Core pretty-printer doesn't print # on unboxed literals -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10104 | simplCore/should_compile/T8274 | Blocking: | Differential Revisions: Phab:D678 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"89458eba5721de1b6b3378415f26e110bab8cc0f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="89458eba5721de1b6b3378415f26e110bab8cc0f" Pretty-print # on unboxed literals in core Summary: Ticket #10104 dealt with showing the '#'s on types with unboxed fields. This commit pretty prints the '#'s on unboxed literals in core output. Test Plan: simplCore/should_compile/T8274 Reviewers: jstolarek, simonpj, austin Reviewed By: simonpj, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D678 GHC Trac Issues: #8274 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 13:25:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 13:25:44 -0000 Subject: [GHC] #10107: Add Functor etc. to Data.Monoid wrappers In-Reply-To: <045.31f9fd043cf1068180e128aefcf56dfc@haskell.org> References: <045.31f9fd043cf1068180e128aefcf56dfc@haskell.org> Message-ID: <060.459c1544f38bea36987ee4fd58c77b60@haskell.org> #10107: Add Functor etc. to Data.Monoid wrappers -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4880 | Blocking: | Differential Revisions: Phab:D673 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"4e6bcc2c8134f9c1ba7d715b3206130f23c529fb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4e6bcc2c8134f9c1ba7d715b3206130f23c529fb" Add various instances to newtypes in Data.Monoid Summary: Add Functor instances for Dual, Sum and Product Add Foldable instances for Dual, Sum and Product Add Traversable instances for Dual, Sum and Product Add Foldable and Traversable instances for First and Last Add Applicative, Monad instances to Dual, Sum, Product Add MonadFix to Data.Monoid wrappers Derive Data for Identity Add Data instances to Data.Monoid wrappers Add Data (Alt f a) instance Reviewers: ekmett, dfeuer, hvr, austin Reviewed By: dfeuer, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D673 GHC Trac Issues: #10107 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 14:07:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 14:07:12 -0000 Subject: [GHC] #17: Separate warnings for unused local and top-level bindings In-Reply-To: <047.fe4cdb312b5d86f34d27df1115f2c91a@haskell.org> References: <047.fe4cdb312b5d86f34d27df1115f2c91a@haskell.org> Message-ID: <062.d9cf5489c3a3c5329dd6dd21226b2e7e@haskell.org> #17: Separate warnings for unused local and top-level bindings -------------------------------------+------------------------------------- Reporter: magunter | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: None Resolution: fixed | Keywords: -fwarn- Operating System: Unknown/Multiple | unused-binds newcomer Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #3283 | Test Case: | Blocking: | Differential Revisions: Phab:D591 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: None => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 14:07:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 14:07:53 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.96c8375f16e99feb69f75269c214ee43@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D669 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 14:10:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 14:10:15 -0000 Subject: [GHC] #8274: Core pretty-printer doesn't print # on unboxed literals In-Reply-To: <048.0e77035003859b63254a7c6b1235c7cc@haskell.org> References: <048.0e77035003859b63254a7c6b1235c7cc@haskell.org> Message-ID: <063.46253b19012c23eb49af16e1145c9ea1@haskell.org> #8274: Core pretty-printer doesn't print # on unboxed literals -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10104 | simplCore/should_compile/T8274 | Blocking: | Differential Revisions: Phab:D678 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 14:10:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 14:10:49 -0000 Subject: [GHC] #10107: Add Functor etc. to Data.Monoid wrappers In-Reply-To: <045.31f9fd043cf1068180e128aefcf56dfc@haskell.org> References: <045.31f9fd043cf1068180e128aefcf56dfc@haskell.org> Message-ID: <060.82beac329d06a65ede59906a93e608ec@haskell.org> #10107: Add Functor etc. to Data.Monoid wrappers -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4880 | Blocking: | Differential Revisions: Phab:D673 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 15:08:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 15:08:20 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2310133=3A_Probleml=C3=B6sung_pur-_durch_ad?= =?utf-8?q?vana_tone_abnehmen?= Message-ID: <045.6e63989c0928b0a7b0b56fb1dee53f9e@haskell.org> #10133: Probleml?sung pur- durch advana tone abnehmen -------------------------------------+------------------------------------- Reporter: betwig | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Eine erfolgsversprechende Di?tstrategie mit Advana.Tone & Advana.Cleanse sind ein Geheimrezept im Gesundheitssektor. Dabei sind die Di?tmittel 100% nat?rlich und f?r die Gesundheit unbedenklich. Durch die Erfahrung mit den Produkten ist bewiesen wurden, dass die neue Di?tmethode ?ber wenige Wochen bis zu 16 kg Gewichtsverlust bringt. Diese Ergebnisse sind bei anderen Schlankmachern bis heute in keiner Weise beobachtet wurden, diese bahnbrechende Di?tstrategie ist also sehr vielversprechend. Erfahrungsrezensionen der K?ufer mit Advana.Tone & Advana.Cleanse Mithilfe von diesen Di?tpillen k?nnen hunderte Anwender nun wiederum zu dem Traumk?rper finden und deswegen zu gew?nschter Lebensqualit?t zur?ckfinden. Sind erstmal f?r den Stoffwechsel unabdingbare Prozesse im K?rper in Gang gesetzt, kann zu k?rperlicher Kraft gefunden werden. Die Inhaltstoffe und Wirkweise von Advana-Tone & Advana.Cleanse In der neuen Di?t werden neu entwickelte Stoffe verwendet, die eine Entschlackung des K?rpers anregen. [http://www.advana-tone.net/ Advana Tone] unterst?tzt die K?rperfett-Verbrennung und Advana.Cleanse sorgt f?r eine Entschlackung des K?rpers. Die Zusammensetzung dieser neuen Di?tprodukte sind unter anderem die Acai-Beere und ein Extrakt aus gr?nem Tee. Die Beeren der Acai enthalten viele gesunde Spurenelemente und Gr?ner-Tee-Extrakt enth?lt Abwehr- Substanzen. Advana-Tone & Advana.Cleanse im Test wir empfehlen diese Di?t-Methode, da sie sehr vielen Personen helfen konnte und nicht zuletzt unser eigenes Testverfahren beste Testergebnisse gezeigt hat. Aber nicht nur beim Abnehmen helfen die Di?tpillen, sie sind au?erdem bei Profi-Bodybuildern f?r die fettminimierende doch gleichzeitig Muskel-erhaltenden Wirkungsweise ber?hmt. Die Substanzen in den Produkten sind allesamt klinisch getestet wurden und ihre Wirkung bewiesen. Zur Bestellweise von Advana Tone & Advana-Cleanse Die Hersteller sind ein gepr?ftes Unternehmen, das f?r die wirksamen Naturprodukte gesch?tzt ist. Die K?ufer k?nnen nachweisen, dass der Anbieter sehr zuverl?ssig ist, eine Best?tigung daf?r ist die Geld-zur?ck- Garantie.Diese Geld-zur?ck Garantie kann verlangt werden, sollten die Di?tprodukte bei einer Person wirkungslos sein. Die Produkte k?nnen ?ber das Internet bestellt werden und k?nnen den Empf?nger innerhalb eines kurzen Zeitraums erreichen. M?chte man sich tiefer zu den Di?tprodukten erkundigen, k?nnen verschiedene Testberichte im WWW aufgerufen werden. Dar?ber hinaus kann man sich ?ber die Inhaltsstoffe belesen, die auf der Herstellerseite aufgelistet sind. Bei zus?tzlichen Nachfragen kann man sich via Anfrage an den Hersteller richten um weitere Informationen ?ber [http://www.advana-tone.net/category/advana-cleanse/ Advana Tone] und Advana Cleanse zu erlangen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 15:26:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 15:26:18 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error Message-ID: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Howsagoin, This is a report about ghci (7.8.4) with CLaSH 0.4.1 I have a collection of modules that show an odd error. I don't want to send them to the list but I can send them to the developers if they think the described behaviour is definitely an error, which I suspect it is. When I write: > (a,b) = expression I get a type error about an occurs check: cannot construct infinite type: t0 ~ (t0 + 1) -1. The error message doesn't mention t0. However, when I leave out the pattern matching on the tuple and write > var = expression > a = fst var > b = snd var where var is a fresh variable, everything is fine. This is odd, because all I did was stripping off the pattern matching. To make sure, I also tried > var = expression > (a,b) = var This also gave the same type checking error. If there's anybody willing to have a look at this, please feel free to contact me by email. If you think I should produce a small example, also please let me know, but please note that it already took me several hours before I found that leaving out the pattern matching solved the problem:-( TIA for your time. Marc van Dongen dongen at cs.ucc.ie -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 15:29:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 15:29:34 -0000 Subject: [GHC] #10132: Inconsistent kind polymorphism for top-level and associated type families In-Reply-To: <046.686d0ef50515818913143703d40559ce@haskell.org> References: <046.686d0ef50515818913143703d40559ce@haskell.org> Message-ID: <061.0017cff941c3253fbf5510bb4d2fa6a5@haskell.org> #10132: Inconsistent kind polymorphism for top-level and associated type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I concur with everything above. Indeed, I believe the statement in bold has been the guiding principle all along, but perhaps not well articulated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 15:36:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 15:36:09 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.6b208e0641e4e058a8a073c47c6b207e@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D632 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => normal * milestone: 7.10.1 => 7.12.1 Comment: Moving out to 7.12 for now pending a better test case/example of where this is going wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 15:44:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 15:44:00 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.9379009b9000441324dde16496086147@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That is indeed odd. Does it happen with 7.10? If you can produce a small example I'd definitely look at it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 18:35:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 18:35:15 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.bbb15d94953de6c22c93ab0c20978884@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * milestone: => 7.12.1 Comment: Encouraged by Iavor Diatchki and Adam Gundry, I've realized that my comment:4 is utterly wrong -- !MikeIzbicki's proposal is reasonable. Concretely, I propose: * `GeneralizedNewtypeDeriving` for classes with associated types define new associated type instances that "look through" to the underlying type instance. This satisfies Mike's original example. To my comment:1, it says `Int`. And, this proposal works for comment:3. Note that associated `data` instances will still be prohibited -- these are not covered by this ticket. I can implement in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 3 18:37:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Mar 2015 18:37:40 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.0ce145699f3bedf124487d6e412f792c@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): If you're trying to minimize further, I have a hunch that type families (perhaps even looping ones) are to blame, somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 00:33:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 00:33:31 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.3162e1211fe701e21d1b7bfa582fcf13@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: merge Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Cross Operating System: Linux | compiling Type of failure: Building GHC | Architecture: x86 failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 06:35:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 06:35:39 -0000 Subject: [GHC] #10135: This Saturday February RageDNA Message-ID: <051.d485d90847cfd387bde92b65ef66d4b0@haskell.org> #10135: This Saturday February RageDNA -------------------------------------+------------------------------------- Reporter: | Owner: RTromeen1955 | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: RageDNA | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: RageDNA Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This Saturday February 28th (for the Central region, South and East) in CONDEPAH facilities in the Olympic Village from 9:00 am. Similarly the same [http://supertestoboostsfacts.com/ragedna/ RageDNA] activity will be held on Saturday March 7 (North Zone and West) at the premises of VIP Nautilus Gym San Pedro Sula from 9:00 am This activity has no cost, so they are invited to be trained and learn about our sport and the basis for this 2015... http://supertestoboostsfacts.com/ragedna/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 06:36:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 06:36:35 -0000 Subject: [GHC] #10136: Female athletes RageDNA Message-ID: <051.f7542f94521c4cc14f027007c3143fc9@haskell.org> #10136: Female athletes RageDNA -------------------------------------+------------------------------------- Reporter: | Owner: RTromeen1955 | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: RageDNA | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: RageDNA Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Female athletes go prepared and take appropriate sports clothing, as the workshop will be theoretical and practical. [http://supertestoboostsfacts.com/ragedna/ RageDNA] Also for male athletes come prepared athletically, since the seminar includes the art of posing. Do not miss this opportunity offered by the highest authority of our sport IFBB in Honduras to learn more about the world of bodybuilding and fitness, can also share and meet with leading and experienced athletes in our sport.. http://supertestoboostsfacts.com/ragedna/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 08:30:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 08:30:53 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.83d8b452ccd090eb49dc186d11acadb0@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): Thanks. The modules that cause it are already small. I'll try and minimise further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 09:22:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 09:22:39 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.2ea8e12f75168625c0e4d980d5b20ce7@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): OK. I've managed to trim down the problem to a few lines. I'm including the contents of three files (it wasn't clear how to attach). Dummy1, which mainly contains type definitions that are needed in my real modules, Dummy2, which contains a datatype and a function, the type of which ``causes'' the problem, and Dummy3, which has the bug. If you compile Dummy3, you get an error. If you comment that line out and uncomment the three previous lines, you'll see that all is fine. In short, I wouldn't expect this behaviour (but I haven't programmed in Haskell for a long time). {{{ > -- Dummy1.lhs > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE MultiParamTypeClasses #-} > module Dummy1( Dummy1, Exponential, Positive ) where > import CLaSH.Prelude > data Dummy1 n a = Dummy1 > { tree :: Vec n a -- | The converging computation. > } deriving Show > type Exponential n > = ( Positive n > , KnownNat (2^n) > , KnownNat ((2^n)-1) > , KnownNat ((2^n)-2) > , KnownNat ((2^(n-1))+((2^(n-1))-1)) > , (((2^n)-1)+1)~(2^n) > , (((2^n)-2)+1)~((2^n)-1) > , ((2^(n-1)-1)*2)~(2^n-2) > , (2^n-2+1)~((2^(n-1))+((2^(n-1))-1)) > , (((2^(n-1))+((2^(n-1))-1))*2)~((2^n)+((2^n)-2)) > ) > type Positive n > = ( KnownNat n > , KnownNat (n-1) > , ((n-1)+1)~n > ) }}} {{{ > -- Dummy2.lhs > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE AllowAmbiguousTypes #-} > module Dummy2( Dummy2, nextDummy2 ) where > import CLaSH.Prelude > import Dummy1 > -- | Data type for arc consistency convergence circuit > -- | * The delay of the circuit is @2*(n+d)@. > data Dummy2 n d = Dummy2 > { dummy :: Vec ((n+d)) Bool > } deriving Show > nextDummy2 > :: ( KnownNat n > , KnownNat d > , Exponential (n+d) > , Positive (2*(n+d)) > ) > => Dummy2 n d > -> ( Dummy2 n d, Bool ) > nextDummy2 cv = error [] }}} {{{ > -- Dummy3.lhs > {-# LANGUAGE MultiParamTypeClasses #-} > module Dummy3( Dummy3 ) where > import CLaSH.Prelude > import Dummy1 > import Dummy2 > data Dummy3 n d = Dummy3 > { dummy2 :: Dummy2 n d > } deriving Show > nextDummy3 > :: ( > Exponential d > , Exponential n > , Exponential (n+d) > , Positive (2*(n+d)) > , ((2^n)*(2^d))~(2^(n+d)) > ) > => Dummy3 n d -> Dummy3 n d > nextDummy3 ac > = Dummy3 { dummy2 = dummyFst } > where -- dummy2' = nextDummy2 (dummy2 ac) > -- dummyFst = fst dummy2' > -- dummySnd = snd dummy2' > (dummyFst,dummySnd) = nextDummy2 (dummy2 ac) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 10:08:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 10:08:38 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.0b047f7b8051ca5b0bdcb2d4e568b092@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | typechecker/should_fail/T7854 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by simonpj): Thomie, thanks for working on this. Inspired by your patches I can see a simpler way to achieve the same goal, so I'll do that. Specifically I plan to do this: * Fix the original bug simply by always doing a `checkValidType` on the entire selector-id type. That includes an ambiguity check which is precisely what we need. * Implement the check when `ConstrainedClassMethods` is ''off'' as a special check that does nothing else. * As comment:4 acknowledges, GHC has not been making the claimed check for ages. Rather than making `ConstrainedClassMethods` on by default (as you propose), I plan to make it implied by `MultiParamTypeClasses`, which means that we are out of Haskell-98 land anyway. This means that some programs may break, but (a) the error message suggests adding `ConstrainedClassMethods` (b) the fix is easy. If necessary (e.g. on a Stackage run) we can make it on-by-default in 7.10 to ease transition. Commit coming. Thanks for unblocking this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 10:30:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 10:30:10 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.622740340d88858d7e1d7c307b6ce187@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): So, to be more specific, the recipe is this: {{{ class C a where type T a op :: a -> a newtype T a = MkT deriving( C ) }}} Here the `deriving` clause would generate {{{ instance C => C (T a) where type T (T a) = T op = coerce (op :: -> ) }}} As usual, a wiki page to explain the details when we have to eta-reduce the newtype, etc, would be helpful. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 11:15:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 11:15:12 -0000 Subject: [GHC] #2991: .tix file generation broken with -fhpc and --make flags with lhs modules In-Reply-To: <045.fbdf830be4083dc434ba708ecd719a55@haskell.org> References: <045.fbdf830be4083dc434ba708ecd719a55@haskell.org> Message-ID: <060.974aa3e94cdc939fe059a8096c27d3c4@haskell.org> #2991: .tix file generation broken with -fhpc and --make flags with lhs modules -------------------------------------+------------------------------------- Reporter: ppavel | Owner: andy@? Type: bug | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.10.1 Resolution: | Keywords: hpc make Operating System: Unknown/Multiple | lhs Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: hpc/T2991 | Blocking: | Differential Revisions: Phab:D701 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => hpc/T2991 * differential: => Phab:D701 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 11:58:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 11:58:09 -0000 Subject: [GHC] #10102: GHC inlines past lambda in do-notation In-Reply-To: <046.54878955c94cdec15cc1b787f40cba48@haskell.org> References: <046.54878955c94cdec15cc1b787f40cba48@haskell.org> Message-ID: <061.e762877ce7d42d9e0ab36bc8453088f9@haskell.org> #10102: GHC inlines past lambda in do-notation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ee56dc56a4a0f556894c4d2bd04c3d4ca73e95a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ee56dc56a4a0f556894c4d2bd04c3d4ca73e95a1" Tidy up and improve comments about one-shot info (Triggered by investigating Trac #10102 etc.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 11:58:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 11:58:09 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.1612721acc07d943e30e097ad37b7d7b@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | typechecker/should_fail/T7854 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f66e0e695b0377c469fbe877d4850fc0ebca2010/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f66e0e695b0377c469fbe877d4850fc0ebca2010" A raft of small changes associated with -XConstrainedClassMethods See Trac #7854. Specifically: * Major clean up and simplification of check_op in checkValidClass; specifically - use checkValidType on the entire method-selector type to detect ambiguity - put a specific test for -XConstrainedClassMethods * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses (a bit ad-hoc but see #7854), and document in the user manual. * Do the checkAmbiguity test just once in TcValidity.checkValidType, rather than repeatedly at every level. See Note [When to call checkAmbiguity] * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous. (It's a rather magic function.) * Improve location info for check_op in checkValidClass * Update quite a few tests, which had genuinely-ambiguous class method signatures. Some I fixed by making them unambiguous; some by adding -XAllowAmbiguousTypes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 12:05:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 12:05:11 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.aaa9b7b005587d399f13cf14a0e81836@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * testcase: typechecker/should_fail/T7854 => module/mod39 * resolution: => fixed Comment: OK done. I suggest we don't push this to 7.10 in case it breaks things. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 13:07:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 13:07:16 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.0b52b12e06f8b978174c86581e2d3692@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): It looks as if the constraint @((n-1)+1)~n@ is the cause of the error. Thanks to Christiaan Baaij for finding this out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 13:22:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 13:22:54 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.72ea2e044287021131ba5bdee9d81b28@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Does that mean you can simplify still further? `Exponential` is still a pretty big constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 13:43:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 13:43:46 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.abf78eaa387a643182edc7cd75663d1a@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): OK Here's the simplest example. The problem goes away if you don't use @Positive (2*(n+d))@ but just @Positive (n+d)@. {{{ > module Dummy( Dummy ) where > import CLaSH.Prelude > type Positive n > = ( KnownNat n > , KnownNat (n-1) > , ((n-1)+1)~n > ) > data Dummy n d = Dummy > { vec :: Vec n (Vec d Bool) > } deriving Show > nextDummy > :: ( KnownNat n > , KnownNat d > , Positive (2*(n+d)) > ) > => Dummy n d -> Dummy n d > nextDummy d > = Dummy { vec = vec dFst } > where -- d2' = nextDummy' d > -- dFst = fst d2' > -- dSnd = snd d2' > (dFst,dSnd) = nextDummy' d > nextDummy' > :: ( KnownNat n > , KnownNat d > , Positive (2*(n+d)) > ) > => Dummy n d > -> ( Dummy n d, Bool ) > nextDummy' _ = error [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 13:45:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 13:45:43 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.d325199ceb3ba060c4b3bcf0ff0156d9@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3aa2519ec29156f57a862a033bc7a902b742a2e0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3aa2519ec29156f57a862a033bc7a902b742a2e0" Check for equality before deferring This one was a bit of a surprise. In fixing Trac #7854, I moved the checkAmbiguity tests to checkValidType. That meant it happened even for monotypes, and that turned out to be very expensive in T9872a, for reasons described in this (new) Note in TcUnify: Note [Check for equality before deferring] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Particularly in ambiguity checks we can get equalities like (ty ~ ty). If ty involves a type function we may defer, which isn't very sensible. An egregious example of this was in test T9872a, which has a type signature Proxy :: Proxy (Solutions Cubes) Doing the ambiguity check on this signature generates the equality Solutions Cubes ~ Solutions Cubes and currently the constraint solver normalises both sides at vast cost. This little short-cut in 'defer' helps quite a bit. I fixed the problem with a quick equality test, but it feels like an ad- hoc solution; I think we might want to do something in the constraint solver too. (The problem was there all along, just more hidden.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 13:45:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 13:45:43 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.ee27ec528776d26f4c2adf22d63f14fc@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9dc0d63cd7231392320e4afcfe78102801126d34/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9dc0d63cd7231392320e4afcfe78102801126d34" Three other test updates following the fix to Trac #7854 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 14:36:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 14:36:48 -0000 Subject: [GHC] #10118: No ambiguity check when `ConstrainedClassMethods` is on In-Reply-To: <045.5132acf01a91a22dd01f11d8230744c0@haskell.org> References: <045.5132acf01a91a22dd01f11d8230744c0@haskell.org> Message-ID: <060.cb95ce4f5d3f136b33d576d4540e95a1@haskell.org> #10118: No ambiguity check when `ConstrainedClassMethods` is on -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | typecheck/should_fail/T10118 Related Tickets: #7854 | Blocking: | Differential Revisions: Phab:D686 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Fixed by f66e0e695b0377c469fbe877d4850fc0ebca2010 (#7854). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 14:37:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 14:37:30 -0000 Subject: [GHC] #10119: Class methods must always mention the class variable In-Reply-To: <045.c4e7c6552a1c88ca34b36be1aea67501@haskell.org> References: <045.c4e7c6552a1c88ca34b36be1aea67501@haskell.org> Message-ID: <060.2d90b8cbd63fe1fc3110c7f1037b810f@haskell.org> #10119: Class methods must always mention the class variable -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | typecheck/should_fail/T10119 Related Tickets: #7854, #10118 | Blocking: | Differential Revisions: Phab:D687 -------------------------------------+------------------------------------- Comment (by thomie): Fixed by f66e0e695b0377c469fbe877d4850fc0ebca2010 (#7854). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 14:38:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 14:38:44 -0000 Subject: [GHC] #10119: Class methods must always mention the class variable In-Reply-To: <045.c4e7c6552a1c88ca34b36be1aea67501@haskell.org> References: <045.c4e7c6552a1c88ca34b36be1aea67501@haskell.org> Message-ID: <060.9f151a8df693da786ada4e7bffd5bb9b@haskell.org> #10119: Class methods must always mention the class variable -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7854, #10118 | Differential Revisions: Phab:D687 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: typecheck/should_fail/T10119 => * resolution: => fixed Comment: Closing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 14:39:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 14:39:05 -0000 Subject: [GHC] #10118: No ambiguity check when `ConstrainedClassMethods` is on In-Reply-To: <045.5132acf01a91a22dd01f11d8230744c0@haskell.org> References: <045.5132acf01a91a22dd01f11d8230744c0@haskell.org> Message-ID: <060.10f8aa7a63837587a1bed3458af4dd1d@haskell.org> #10118: No ambiguity check when `ConstrainedClassMethods` is on -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7854 | Differential Revisions: Phab:D686 -------------------------------------+------------------------------------- Changes (by thomie): * testcase: typecheck/should_fail/T10118 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 16:30:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 16:30:44 -0000 Subject: [GHC] #10137: Rewrite switch code generation Message-ID: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Inspired by #10124 I looked at the code generation for enumeration and integer types, and I think this can be improved in a few ways. My goals are: * Fancier code for integer types. Currently, the code for enumeration types will emit jump tables for dense choices; there is no reason to treat integer types differently. * The ability to behave differently if some of the cases are equal, and, as an extension of that, * The possibility to create branchless code if multiple checks would go to the same jump. The current scheme is roughly: * When we generate Cmm code for a STG case expression, we handle enumeration types and literals separately. * At this point, the decisions about what code to generate are made (jump tables (but only for enumeration types) or if-then-else trees). * The Common Block Optimization on Cmm happens later in the pipeline, making it non-trivial to detect branches that do the same thing. My plan is the following: * In the STG?Cmm transformation, floats will be handled separately. Matching against literals literals is fishy anyways, so my suggestion is to simply generate a linear list of equality checks here ? turning the intended operation (equality test) into something else (comparisons in a if-then-else tree) feels wrong to me for floats. And the rest would not work well for floats, so I?d like to have them out of the way. * The case of enumeration types will be reduced to word literals, and treated the same from now on. * For integer types, no code generation decisions is made at this point. Instead, always a `CmmSwitch` statement is generated. * In a separate Cmm transformation pass, which will run /after/ the common block optimization, we visit all `CmmSwitches` and create proper code for them. I?d like to separate the algorithm that plans the code generation into a function (possibly even module) of its own, so that the decisions can easily by analyized and modified. The algorithm has a few choices to make: * If multiple values point to the same code, we can generate branchless code (`y := x == 1 || x == 5 || x = 7; if (y==0) then goto l1 else goto l2`). * If there are whole ranges pointing to the same code, the above can also use comparisons. * If there are dense ranges (i.e. a range with more than half of the possible values mapped to something), we want to generate jump tables from them (still `CmmSwitch` values). * Unless all options are handled by one of these possibilities, they need to be combined using `if-then-else` trees. The `CmmSwitch` constructor needs to change for that. It currently takes a `[Maybe Label]` argument, which is not suitable for before that pass, when its table may be sparse. I think an `IntMap Label` would work nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 16:32:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 16:32:31 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.820c852af9932ca3ec6b85bbd3d3d86e@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, | Differential Revisions: #9661,#10137 | -------------------------------------+------------------------------------- Changes (by nomeata): * related: #6135, #9661 => #6135, #9661,#10137 Comment: I believe that at least some of this can and should be handled in the code generator, where the code generation for branching on integers can be improved anyways. I describe a possible plan in #10137. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 17:22:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 17:22:14 -0000 Subject: [GHC] #2224: -fhpc inteferes/prevents rewrite rules from firing In-Reply-To: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@haskell.org> References: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@haskell.org> Message-ID: <058.e4e779f14fcf8d0434e225c355ab9647@haskell.org> #2224: -fhpc inteferes/prevents rewrite rules from firing -------------------------------------+------------------------------------- Reporter: dons | Owner: andy@? Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.8.2 Resolution: | Keywords: rules, hpc Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by thomie: Old description: > Use case: > > I'm writing tests for rewrite rules, and using HPC to determine if rules > were fired (and their code exercised). HPC is quite cool here, since it > lets us see which rules fired, without needing to explicitly export > functions to test. > > However, -fhpc seems to prevent many rules from firing (likely due to > ticks getting in the way?) > > For example: > > {{{ > import qualified Data.ByteString.Char8 as C > > main = print (C.pack "literal") > }}} > > When compiled normally, triggers a nice rewrite rule: > > {{{ > $ ghc -O2 A.hs -ddump-rule-firings A.hs -c > Rule fired: unpack > Rule fired: Class op show > Rule fired: unpack-list > Rule fired: ByteString packChars/packAddress > Rule fired: unpack > Rule fired: Class op show > Rule fired: unpack-list > Rule fired: ByteString packChars/packAddres > }}} > > Now with -fhpc: > > {{{ > $ ghc -O2 A.hs -ddump-rule-firings A.hs -c -fhpc > Rule fired: unpack > Rule fired: Class op show > Rule fired: unpack-list > Rule fired: unpack > Rule fired: Class op show > Rule fired: unpack-list > }}} > > What's the best way to ensure the same code is exercised with and without > -fhpc here? (I'd quite like to get this working, since rewrite rules > benefit from testing.) New description: Use case: I'm writing tests for rewrite rules, and using HPC to determine if rules were fired (and their code exercised). HPC is quite cool here, since it lets us see which rules fired, without needing to explicitly export functions to test. However, -fhpc seems to prevent many rules from firing (likely due to ticks getting in the way?) For example: {{{ import qualified Data.ByteString.Char8 as C main = print (C.pack "literal") }}} When compiled normally, triggers a nice rewrite rule: {{{ $ ghc -O2 A.hs -ddump-rule-firings -c Rule fired: unpack Rule fired: Class op show Rule fired: unpack-list Rule fired: ByteString packChars/packAddress }}} Now with -fhpc: {{{ $ ghc -O2 A.hs -ddump-rule-firings A.hs -c -fhpc Rule fired: unpack Rule fired: Class op show Rule fired: unpack-list }}} What's the best way to ensure the same code is exercised with and without -fhpc here? (I'd quite like to get this working, since rewrite rules benefit from testing.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 19:12:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 19:12:26 -0000 Subject: [GHC] #10138: hpc does not handle absolute paths correctly Message-ID: <045.9bdca9682fa3d158f8da50db7ac5cc99@haskell.org> #10138: hpc does not handle absolute paths correctly -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code | Version: 7.8.4 Coverage | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See https://github.com/haskell/cabal/issues/2225. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 23:15:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 23:15:05 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.637afa0f3cdc948211a17b088b3c35ca@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Sounds good. I do think that some work can be done in Core. For example: {{{ case x of 1# -> e1 2# -> e2 7# -> e1 _ -> e2 }}} might turn into {{{ case (x ==# 1# `orI#` x ==# 7#) of 0# -> e2 -- False 1# -> e1 -- True }}} I would also '''dearly''' like to implement #8317 to get rid of all those stupid `tagToEnum#` calls that clutter up the code. We don't do this for a stupid reason: #8326. As part of your crusade, dealing with this would be fantastic. I'd be happy to advise/help. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 4 23:20:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Mar 2015 23:20:57 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.ebc838ddba2fba67c2981923be6e8f3d@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The code is small but depends on `import CLaAH.Prelude`. What's that? Can you suck out the important bits and put them in the test case? (I did try `cabal unpack clash` and got `clash-0.1.3.11`, but it didn't contain a `Prelude` module.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 00:32:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 00:32:53 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.9181122170c73723302a7073f3eccb66@haskell.org> #1853: hpc mix files for Main modules overwrite each other -------------------------------------+------------------------------------- Reporter: guest | Owner: AndyGill Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:12 andygill]: > This one is tricky to fix, because of a baked in assumption. If anyone wants to help, or if I can find a willing student, I can give guidance about how to fix it. @andygill. I am currently looking at hpc. Do you think this issue is worth fixing? Multiple programs in the same directory can be nicely handled using `-main-is`. The following doesn't overwrite any .mix files: {{{#!hs $ cat ProgramA.hs module ProgramA where main = return () $ cat ProgramB.hs module ProgramB where main = return () $ ghc -fhpc -main-is ProgramA ProgramA $ ghc -fhpc -main-is ProgramB ProgramB $ ls .hpc ProgramA.mix ProgramB.mix }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 07:59:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 07:59:40 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.e4136a27fd93f9d8f28d490ba55252e0@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317 | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #9157, #8326, #8317 Comment: > The Common Block Optimization on Cmm happens later in the pipeline, making it non-trivial to detect branches that do the same thing. #9157 demonstrates a case where CBE fails, although it definitely shouldn't. Re #8326 I spent several weeks trying to fix it but ultimately I failed. You can find various experimental versions of my code on these branches: [[https://github.com/jstolarek/ghc/tree/T8326-heap-checks|T8326-heap- checks]] [[https://github.com/jstolarek/ghc/tree/T8326-heap-checks-aletr- gc_plan|T8326-heap-checks-aletr-gc_plan]] [[https://github.com/jstolarek/ghc/tree/T8326-heap-checks-alternative- plan|T8326-heap-checks-alternative-plan]] [[https://github.com/jstolarek/ghc/tree/T8326-heap-checks-precompile- alts|T8326-heap-checks-precompile-alts]] though it probably will be easier to write your own code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 08:08:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 08:08:57 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.19fb4a5dd58d5abd9d2861d828590d52@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:3 jstolarek]: > [https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmCommonBlockElim.hs#L62 We check these two block for equality], except that this time we don't ignore the labels and other unique identifiers (eg. [https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmCommonBlockElim.hs#L148 here]). These links are no longer accurate because I didn't link to a particular commit. Here's a fixed version: [https://github.com/ghc/ghc/blob/b8b8d190525b073aa44f7a5bda555e25ea7ef5d6/compiler/cmm/CmmCommonBlockElim.hs#L62 We check these two block for equality], except that this time we don't ignore the labels and other unique identifiers (eg. [https://github.com/ghc/ghc/blob/b8b8d190525b073aa44f7a5bda555e25ea7ef5d6/compiler/cmm/CmmCommonBlockElim.hs#L148 here]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 08:36:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 08:36:41 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.51d537e1326145d0a32e854db258ff1e@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317 | -------------------------------------+------------------------------------- Comment (by nomeata): All very well, but can we please keep this particular ticket for the discussion of better code generation from STG onwards :-) #10124 is more suitable for what we can do in Core, I think. My rewrite will not only fix the issue of branchless cases, but also other (small) deficiencies in the current code (jump tables also for integer types; a better choice for if-then-else branching that leads to larger jump tables). Anyway, I started on wip/T10137, but already my refactoring broke something and I get segfaults :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 13:07:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 13:07:08 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path In-Reply-To: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> References: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> Message-ID: <060.bc8212846b4546ef38b29fe07e1ba760@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: infoneeded Priority: lowest | Milestone: Component: Code Coverage | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: @Kasper: I need your help here. I can't reproduce your problem. Here's what I've tried. Source code: {{{ cat > ./T9619.cabal <=1.2 executable T9619 main-is: T9619.hs build-depends: base test-suite IntegrationTests type: exitcode-stdio-1.0 main-is: IntegrationTests.hs ghc-options: -main-is IntegrationTests other-modules: ModuleATest build-depends: base test-suite UnitTests type: exitcode-stdio-1.0 main-is: UnitTests.hs ghc-options: -main-is UnitTests other-modules: ModuleATest build-depends: base EOF cat > ./Setup.hs < ./T9619.hs < ./IntegrationTests.hs < ./UnitTests.hs < ./ModuleATest.hs < output dist/hpc/vanilla/mix/ dist/hpc/vanilla/mix/IntegrationTests dist/hpc/vanilla/mix/IntegrationTests/ModuleATest.mix dist/hpc/vanilla/mix/IntegrationTests/IntegrationTests.mix dist/hpc/vanilla/mix/UnitTests dist/hpc/vanilla/mix/UnitTests/ModuleATest.mix dist/hpc/vanilla/mix/UnitTests/UnitTests.mix $ hpc sum dist/hpc/vanilla/tix/IntegrationTests/IntegrationTests.tix dist/hpc/vanilla/tix/UnitTests/UnitTests.tix --union Tix [TixModule "IntegrationTests" 1693426709 3 [1,1,1],TixModule "ModuleATest" 897400108 2 [2,2],TixModule "UnitTests" 1821344755 3 [1,1,1]] $ cabal --version cabal-install version 1.23.0.0 using version 1.23.0.0 of the Cabal library $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 }}} It all seems to work to me. The `ModuleATest.mix` file is indeed generated twice, but it doesn't seem to bother `hpc sum`. You mention "When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present". What is the command you use to run `hpc sum`. My understanding is that `hpc sum` only takes .tix files, not .mix files. I must be missing something, so please clarify. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 13:47:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 13:47:29 -0000 Subject: [GHC] #3321: -fhpc assumes original sources relative to the current directory In-Reply-To: <045.e36e70091ef09c2231ae7feacc97785c@haskell.org> References: <045.e36e70091ef09c2231ae7feacc97785c@haskell.org> Message-ID: <060.fa69780136cd46a73d4394699b639505@haskell.org> #3321: -fhpc assumes original sources relative to the current directory -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.10.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: ttuegel (added) * status: new => closed * resolution: => worksforme Comment: @duncan, @ttuegel: I think this works now (the issue was opened 7 years ago). Please reopen if you find ghc still doesn't handle the combination of `-fhpc` and `-i` properly. {{{ $ mkdir a $ mkdir b $ cat > ./a/A.hs < ./B.hsc < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 14:19:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 14:19:38 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path In-Reply-To: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> References: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> Message-ID: <060.2acb0ecc676ac5603d4fd67940ad9b31@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: infoneeded Priority: lowest | Milestone: Component: Code Coverage | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Ok, it's not `hpc sum` that fails, only `hpc markup`: {{{ $ hpc markup dist/hpc/vanilla/tix/IntegrationTests/IntegrationTests.tix --hpcdir=dist/hpc/vanilla/mix/IntegrationTests/ --hpcdir=dist/hpc/vanilla/mix/UnitTests/ hpc: found 2 instances of ModuleATest in ["./.hpc","./dist/hpc/vanilla/mix/UnitTests/","./dist/hpc/vanilla/mix/IntegrationTests/"] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 14:49:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 14:49:25 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path In-Reply-To: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> References: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> Message-ID: <060.3b0606c389c0d70924d1de01ee9a009c@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: infoneeded Priority: lowest | Milestone: Component: Code Coverage | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Kasper): Ok, sorry, bad bug report, I did indeed do a combination of hcp markup and hpc sum. I moved away from this approach right now, so I don't really have the problem anymore, clarification might have been very difficult. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 16:11:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 16:11:18 -0000 Subject: [GHC] #10138: hpc does not handle absolute paths correctly In-Reply-To: <045.9bdca9682fa3d158f8da50db7ac5cc99@haskell.org> References: <045.9bdca9682fa3d158f8da50db7ac5cc99@haskell.org> Message-ID: <060.562f0104af9458f31103758fb8aa4da9@haskell.org> #10138: hpc does not handle absolute paths correctly -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Code Coverage | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: hpc/T10138 Related Tickets: | Blocking: | Differential Revisions: Phab:D703 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => hpc/T10138 * differential: => Phab:D703 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 21:20:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 21:20:17 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path In-Reply-To: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> References: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> Message-ID: <060.821b2cad9e4ce19d05e7a0538b069172@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D704 -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => patch * differential: => Phab:D704 * milestone: => 7.12.1 Comment: A potential fix can be found here (pending validation): https://github.com/ghc/packages-hpc/tree/wip/T9619 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 22:30:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 22:30:47 -0000 Subject: [GHC] #10132: Inconsistent kind polymorphism for top-level and associated type families In-Reply-To: <046.686d0ef50515818913143703d40559ce@haskell.org> References: <046.686d0ef50515818913143703d40559ce@haskell.org> Message-ID: <061.b66aa6d519a6cc9c74f01e3116796e5c@haskell.org> #10132: Inconsistent kind polymorphism for top-level and associated type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b833bc2767d7a8c42093cf2994453f70df206c8d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b833bc2767d7a8c42093cf2994453f70df206c8d" User manual section to document the principles of kind inference This just documents the conclusions of Trac #10132 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 5 22:33:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Mar 2015 22:33:40 -0000 Subject: [GHC] #10132: Inconsistent kind polymorphism for top-level and associated type families In-Reply-To: <046.686d0ef50515818913143703d40559ce@haskell.org> References: <046.686d0ef50515818913143703d40559ce@haskell.org> Message-ID: <061.c2e7500417e4c8834976402b691db04a@haskell.org> #10132: Inconsistent kind polymorphism for top-level and associated type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 00:03:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 00:03:01 -0000 Subject: [GHC] #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) In-Reply-To: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> References: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> Message-ID: <062.741e600bb1c63acc7623e6d86455dc7a@haskell.org> #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: feature request | Status: closed Priority: low | Milestone: ? Component: Compiler | Version: 7.10.1-rc1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #6016 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #6016 Comment: I am bringing you good news from #6016. A fix for BOMs in Haskell source files will be in 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 00:25:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 00:25:40 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.39ee41a43649fafc37a0f7114a83173a@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Probably not Mac specific. @hedayaty: did you manage to create a minimal example reproducing the bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 00:53:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 00:53:10 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.5e398b452397e3379e9d1ce459a3bee1@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hedayaty): I made a new attachment. This is minimal as far the generated code can go. Please see if you can tackle the bug on this. BTW, do you mind if I prioritize the bug? It is blocking adding a feature in our product. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 01:07:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 01:07:28 -0000 Subject: [GHC] #9995: :info enhancements In-Reply-To: <046.2fdc2e62d570cea4f69a1c002298abe9@haskell.org> References: <046.2fdc2e62d570cea4f69a1c002298abe9@haskell.org> Message-ID: <061.4fe95c3e5e7af1ce582c74901c6bd638@haskell.org> #9995: :info enhancements -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #2986 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #2986 Comment: A patch for point 2 (`:instances`) is in the works in #2986. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 01:24:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 01:24:21 -0000 Subject: [GHC] #10064: Add support for "foo"## literals to MagicHash In-Reply-To: <049.cb303598e29d32fcc2ec0d8e38051be4@haskell.org> References: <049.cb303598e29d32fcc2ec0d8e38051be4@haskell.org> Message-ID: <064.49878477ff53df61f3b7c4d0f1fb085f@haskell.org> #10064: Add support for "foo"## literals to MagicHash -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 02:31:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 02:31:20 -0000 Subject: [GHC] #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself In-Reply-To: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> References: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> Message-ID: <064.8d0ab2c6f94efa23b0fbfdabdd565aed@haskell.org> #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: test Operating System: Unknown/Multiple | framework makefile Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D705 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D705 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 06:40:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 06:40:43 -0000 Subject: [GHC] #10139: Coercible causes ghc to hang Message-ID: <053.ded1fc4757c965f068c092100f8f55ce@haskell.org> #10139: Coercible causes ghc to hang -------------------------------------+------------------------------------- Reporter: | Owner: nitromaster101 | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider my two instance declarations. The second one will hang ghc. If I change (coerce) to (coerce :: Normal a -> Sized a) it compiles fine. The first declaration also works fine. {{{ {-# LANGUAGE TypeFamilies, FlexibleInstances #-} import qualified Data.FingerTree as FT import GHC.Exts class DOps a where plus :: a -> D a -> a type family D a :: * type instance D (FT.FingerTree (Size Int, v) (Sized a)) = [Diff (Normal a)] type family Normal a :: * data Diff a = Add Int a newtype Sized a = Sized a newtype Size a = Size a -- This works: instance (FT.Measured (Size Int, v) (Sized a), Coercible (Normal a) (Sized a)) => DOps (FT.FingerTree (Size Int, v) (Sized a)) where plus = foldr (\(Add index val) seq -> FT.singleton ((coerce) val)) -- This hangs: instance (FT.Measured (Size Int, v) (Sized a), Coercible (Normal a) (Sized a)) => DOps (FT.FingerTree (Size Int, v) (Sized a)) where plus = foldr (flip f) where f seq x = case x of Add index val -> FT.singleton ((coerce) val) }}} {{{ $ ~/downloads/ghc-7.10.0.20150123/out/bin/ghci --version The Glorious Glasgow Haskell Compilation System, version 7.10.0.20150123 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 06:48:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 06:48:30 -0000 Subject: [GHC] #10139: Coercible causes ghc to hang In-Reply-To: <053.ded1fc4757c965f068c092100f8f55ce@haskell.org> References: <053.ded1fc4757c965f068c092100f8f55ce@haskell.org> Message-ID: <068.6253dbc915dcbd2f3da7515dd00ed401@haskell.org> #10139: Coercible causes ghc to hang -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): This is presumably related to #10079 and #7788. Fix is forthcoming in the next few days. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 09:30:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 09:30:59 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.e4a89cc3c3363c2b9ed6ff9467b7ce78@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:108 goldfire]: > Replying to [comment:105 dorchard]: > > what about adding a kind of injectives `>->`? e.g.`* >-> *`is the kind of injective type functions > > This is very much along the lines of what Jan and I proposed in our "Promoting Functions to Type Families" paper ([http://www.cis.upenn.edu/~eir/papers/2014/promotion/promotion.pdf here]). Not exactly, I think. At the moment `->` kind classifies term-level functions (non-injective, non-generative, can be partially applied), type constructors (injective, generative, can be partially applied) and type families (non-injective, non-generative, cannot be partially applied). In our paper we proposed a new kind to classify type functions (families) that are still non-injective and non-generative but can be partially applied just like term-level functions. We addressed the problem of partial application, not injectivity. > GHC assumes all function types (that is, types with kinds that are headed by `->`) are ''generative'' and ''injective''. (...) Thus, the kind `->` denotes a generative, injective function. Are you sure? I would say this is true only for type constructors but perhaps I'm missing something. (I am assuming that also `->` classifies type families although, as you point out, this is not entirely accurate.) Anyway, I can imagine introducing a new kind to distinguish between injective and non-injective applications but, given that we might want a new kind to distinguish between things that can and can't be partially applied at the type level, this does not seem like a good choice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 10:37:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 10:37:25 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.c007c8cad509e387011c50b622175cbd@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): Hi Simon, You must build this with _clash_, which is built on top of ghc. I tried to simplified the example but I couldn't. Still I learnt something. * I removed the need for @CLaSH.Prelude@ and copied a definition for @Vec@ into the @Dummy@ module. I then imported @GHC.TypeLits@ and added lots of pragmas suggested by ghc. After that the module compiled fine. * I then did a bit more inverstigating and found that if I add the pragma @{-# LANGUAGE TypeFamilies #-}@ to the original @Dummy@ module (the one that depends on @CLaSH.Prelude@) solves the problem. Regards, Marc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 10:47:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 10:47:23 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.9af3edf1fc0c6a4b254ec9ac98edd8dd@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): But `clash-0.1.3.11` does not include a module called `CLaSH.Prelude`. You say "You must build this with _clash_, which is built on top of ghc". Can you give a sequence of steps to achieve that? From what I can see clash has a huge dependency list {{{ build-depends: ghc >= 6.12 && < 6.13, pretty >= 1.0.1.1 && < 1.1, vhdl >= 0.1.2.1 && < 0.2, haskell98 >= 1.0.1.1 && < 1.1, data-accessor >= 0.2.1.3 && < 2.3, containers >= 0.3 && < 0.4, base >= 4.2 && < 4.3, transformers >= 0.2 && < 0.3, filepath >= 1.1.0.4 && < 1.2, template-haskell >= 2.4.0.1 && < 2.5, data-accessor-template >= 0.2.1.8 && < 0.3, prettyclass >= 1.0 && < 1.1, directory >= 1.0 && < 1.1, tfp >= 0.2 && < 0.4, th-lift >= 0.5.4 && < 0.6, time >= 1.1.4 && < 1.2, utility-ht < 0.0.7 }}} I'm having a hard time believing that installing vhdl (which sounds like a big deal) is crucial to demonstrating the problem. Maybe instead of copying the definition for `Vec` into `Dummy`, make a separate module `Clash.Stubs`, and populate it with the stuff that `Dummy` needs? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 12:15:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 12:15:05 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.1356b1239bdc42b687b0ad26ec565443@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): The main CLaSH page is http://christiaanb.github.io/clash2/. It contains a link to a tutorial. To compile @Dummy.lhs@ with clash, you write _clash Dummy.lhs_. It will call ghc itself. You can also call _clash --interactive Dummy.lhs_, which will call ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 15:07:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 15:07:57 -0000 Subject: [GHC] #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide Message-ID: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've been reading the [http://haskell.inf.elte.hu/docs/7.11.20150306.noWin32/html/users_guide /safe-haskell.html documentation] on Safe Haskell. Cool stuff. Here are some suggestions for improvement, I hope some are useful: * 7.29.1.2 This comment is the first introduction to the pragmas `TrustWorthy` and `Safe`: {{{ -- Either of the following Safe Haskell pragmas would do {-# LANGUAGE Trustworthy #-} {-# LANGUAGE Safe #-} module RIO ... }}} Why is either allowed? I suspect because of the details of this module, but this is not explicitly stated. Furthermore, later it is said that `-XTrustworthy` should be used, not `-XSafe`: "This is done by compiling the RIO module with the -XTrustworthy flag and compiling the Danger module with the -XSafe flag." * 7.29.2 "TemplateHaskell ? Is particularly dangerous, as it can cause side effects even at compilation time" One could now think that `Safe Haskell` does guarantee compilation safety. Since that is not the case, I would remove that sentence (things are explained properly in the Safe Compilation section). * 7.29.2 "Hand crafted instances of the Typeable type class are not allowed in Safe Haskell". Make a mention of the [https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/deriving.html following]: "... since GHC 7.8.1, handwritten (ie. not derived) instances of Typeable are forbidden, and will result in an error." * 7.29.4 After listing `-XSafe`, `-XTrustWorthy`, `-XUnsafe`: "The procedure to check if a module is trusted or not depends on if the -fpackage-trust flag is present. The check is very similar in both cases" There are three cases. * 7.29.4.1. Trust check (-fpackage-trust disabled) "A module M in a package P is trusted by a client C if and only if: Both of these hold: 1. The module was compiled with -XSafe 2. All of M's direct imports are trusted by C" But isn't the latter implied by the former, or the module wouldn't compile? If that is correct, please mention it. Same in the next section (7.29.4.2). * 7.29.4.2 "Having the -fpackage-trust flag also nicely unifies the semantics of how Safe Haskell works when used explicitly and how modules are inferred as safe." Should explicitly be implicitly? I don't understand this sentence regardless. What does nicely unifies mean? * 7.29.4.1 and 7.29.4.2 There is no mention of Safe Haskell Inference in these rules, only "The module was compiled with -XSafe" and "The module was compiled with -XTrustWorthy". I think the following statement should be true, but I'm not sure: "If a module M in a package P is inferred to be Safe by GHC, then it is trusted by client C". Actually, there is only a short mention of safe inference in the introduction, whereas I suspect it should be mentioned everywhere where `-XSafe` is. * 7.29.5 "That is, the use cases outlined and the purpose for which Safe Haskell is intended: compiling untrusted code." Before, "compiling and executing untrusted code" was listed as one of two cases. Now it's mentioned as the single purpose. Minor issue. * 7.29.5 "Say you are writing a Haskell library. Then you probably just want to use Safe inference." I have more of a general question about this: if this is true, then why are there over 200 mentions of `{-# Language Safe #-}` in a checkout of ghc? Is it because 'Safe Haskell Inference' was not added to GHC until version 7.4 (is that true? I inferred it from the difference between the 7.2 and 7.4 user's guides). So maybe modules that need to be compileable with earlier versions of GHC have to specify -XSafe explicitly? Some guidance on this would be helpful. * There are 2 `ulink`s that don't work. Should be `xref`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 15:50:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 15:50:48 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.312ffa70c9a7f648cf6df90761a65cb5@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:109 jstolarek]: > (I am assuming that also `->` classifies type families although, as you point out, this is not entirely accurate.) Right -- `->` does '''not''' classify type families in Haskell today. The only place where `->` describes a type family is in the output of GHCi's `:kind` operator. And, to get that to work, GHC has a gross hack in that GHCi relaxes the "type families must always be saturated" requirement, just to appease users who want to know the shape of their type families. (This gross hack is a great idea from a user's point of view, and I'm not at all suggesting removing it. But it is gross from a type system point of view.) Nowhere in a Haskell source text can `->` classify a type family. So, I think that fact describes the difference between our comments above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 16:20:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 16:20:03 -0000 Subject: [GHC] #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide In-Reply-To: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> References: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> Message-ID: <060.3fdffaf6617e75eae3d26dc5cb25adaf@haskell.org> #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): David, good suggestions here. Would you like to follow them up? Thanks Thomas Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 16:26:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 16:26:00 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.106d444dbb62a22ff6d4a43ac094ab42@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Aha. The missing piece (which I found on the CLaSH page) is that the library in question is `clash-ghc` not `clash`. But I failed immediately {{{ bash$ cabal install clash-ghc --with- ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2 Resolving dependencies... cabal: Could not resolve dependencies: trying: clash-ghc-0.4.1 (user goal) trying: base-4.8.0.0/installed-inp... (dependency of clash-ghc-0.4.1) trying: unbound-0.4.3.1 (dependency of clash-ghc-0.4.1) trying: RepLib-0.5.3.3 (dependency of unbound-0.4.3.1) next goal: template-haskell (dependency of RepLib-0.5.3.3) rejecting: template-haskell-2.10.0.0/installed-inp... (conflict: RepLib => template-haskell>=2.4 && <2.10) rejecting: template-haskell-2.9.0.0 (conflict: base==4.8.0.0/installed- inp..., template-haskell => base==4.7.*) rejecting: template-haskell-2.8.0.0 (conflict: base==4.8.0.0/installed- inp..., template-haskell => base==4.6.*) rejecting: template-haskell-2.7.0.0 (conflict: base==4.8.0.0/installed- inp..., template-haskell => base==4.5.*) rejecting: template-haskell-2.6.0.0 (conflict: base==4.8.0.0/installed- inp..., template-haskell => base==4.4.*) rejecting: template-haskell-2.5.0.0 (conflict: base==4.8.0.0/installed- inp..., template-haskell => base==4.3.*) rejecting: template-haskell-2.4.0.1 (conflict: base==4.8.0.0/installed- inp..., template-haskell => base==4.2.*) rejecting: template-haskell-2.4.0.0 (conflict: base==4.8.0.0/installed- inp..., template-haskell => base>=3 && <4.3) rejecting: template-haskell-2.3.0.1, 2.3.0.0, 2.2.0.0 (conflict: RepLib => template-haskell>=2.4 && <2.10) Backjump limit reached (change with --max-backjumps). }}} I can't even see the code: {{{ bash$ cabal unpack clash-ghc Downloading clash-ghc-0.4.1... cabal: : resource vanished }}} The sad truth is that if it's too hard to reproduce a bug, I just move on to something else. I'd love to look at this, but I can only do so if I can reproduce it, and currently I can't. If you feel motivated to work on a smaller test case, one that doesn't depend on so much extra stuff, then that'd be great. Otherwise we are stalled. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 17:06:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 17:06:28 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.85f0a0765d708114804389641972897e@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): This smells like a "Let should not be generalised" problem. dongen: Does enabling the `MonoLocalBinds` extension fix the problem? Conversely, in your one-module, no-dependencies version, does enabling `NoMonoLocalBinds` cause the problem to appear? The `TypeFamilies` extension implies `MonoLocalBinds`. My guess is that this is a case where using definitions whose types mention type families means that a `let` should not be generalised. And that will be hard to fix without enabling `MonoLocalBinds` by default. Interesting -- I'd love to see that minimal case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 17:16:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 17:16:05 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families Message-ID: <047.0645604fc6dcb528cffc10034076546d@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Take the following definition: {{{ type family G (a :: k) where G Int = Bool G Bool = Int G a = a }}} It compiles in 7.8.3, but not in 7.10.1 RC2. This makes me sad. I will fix. (Found by Jan Stolarek.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 17:22:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 17:22:20 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.679dad773e34859f46e58de2197db7f8@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This looks bad. Release blocker? I assume so. Say if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 17:25:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 17:25:50 -0000 Subject: [GHC] #10142: Documentation for Ix is contradictory around minimal definition Message-ID: <047.81509fc461e889201e078e22917aaf33@haskell.org> #10142: Documentation for Ix is contradictory around minimal definition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.4 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The Haddock documentation for `Ix` [http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html here] says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires `range` and `inRange`. It seems that Haddock is inferring a `MINIMAL` definition where none is in the code. Perhaps a `MINIMAL` should be added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 6 22:50:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Mar 2015 22:50:00 -0000 Subject: [GHC] #5188: Runtime error when allocating lots of memory In-Reply-To: <046.23412d715d1f4494b90774a7c22b4d8d@haskell.org> References: <046.23412d715d1f4494b90774a7c22b4d8d@haskell.org> Message-ID: <061.b0ce0b6cb2d7cc2fd7490f8755b0c624@haskell.org> #5188: Runtime error when allocating lots of memory -----------------------------------+------------------------------------- Reporter: knyblad | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => GHCi crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 00:36:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 00:36:52 -0000 Subject: [GHC] #10143: Separate PprFlags (used by Outputable) from DynFlags Message-ID: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> #10143: Separate PprFlags (used by Outputable) from DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, SDoc computations have full access to the entirety of DynFlags, despite only a minusculely small amount of the data structure being relevant to them. This proposal is to split out a `PprFlags` structure which will be contained in a `DynFlags`, and contain dynamic flags JUST for pretty-printing. There will be a function `pprFlags :: DynFlags -> PprFlags`. This also helps eliminate the circular dependency between `DynFlags` and `Outputable`. This structure is not complete, but it should give a sense for some of the things that need to be put in here: {{{ data PprFlags = PprFlags { pprUserLength :: Int, pprCols :: Int, useUnicode :: Bool, useUnicodeSyntax :: Bool, targetPlatform :: Platform, suppressUniques :: Bool, errorSpans :: Bool, suppressModulePrefixes :: Bool } }}} I have a patch in-progress which factors this out, but I want to get some sign-offs that this is a good refactoring before I finish it. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 01:02:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 01:02:46 -0000 Subject: [GHC] #10143: Separate PprFlags (used by Outputable) from DynFlags In-Reply-To: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> References: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> Message-ID: <060.e4c4023a5e9a0aa78b3193c79eb8709c@haskell.org> #10143: Separate PprFlags (used by Outputable) from DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > At the moment, SDoc computations have full access to the entirety of > DynFlags, despite only a minusculely small amount of the data structure > being relevant to them. This proposal is to split out a `PprFlags` > structure which will be contained in a `DynFlags`, and contain dynamic > flags JUST for pretty-printing. There will be a function `pprFlags :: > DynFlags -> PprFlags`. This also helps eliminate the circular dependency > between `DynFlags` and `Outputable`. > > This structure is not complete, but it should give a sense for some of > the things > that need to be put in here: > > {{{ > > data PprFlags = PprFlags { > pprUserLength :: Int, > pprCols :: Int, > > useUnicode :: Bool, > useUnicodeSyntax :: Bool, > targetPlatform :: Platform, > > suppressUniques :: Bool, > errorSpans :: Bool, > suppressModulePrefixes :: Bool > } > }}} > > I have a patch in-progress which factors this out, but I want to get some > sign-offs that this is a good refactoring before I finish it. > > Thanks! New description: At the moment, SDoc computations have full access to the entirety of DynFlags, despite only a minusculely small amount of the data structure being relevant to them. This proposal is to split out a `PprFlags` structure which will be contained in a `DynFlags`, and contain dynamic flags JUST for pretty-printing. There will be a function `pprFlags :: DynFlags -> PprFlags`. This also helps eliminate the circular dependency between `DynFlags` and `Outputable`. This structure is not complete, but it should give a sense for some of the things that need to be put in here: {{{ data PprFlags = PprFlags { pprUserLength :: Int, pprCols :: Int, useUnicode :: Bool, useUnicodeSyntax :: Bool, targetPlatform :: Platform, suppressUniques :: Bool, errorSpans :: Bool, suppressModulePrefixes :: Bool, printExplicitKinds :: Bool, printExplicitForalls :: Bool, suppressTypeSignatures :: Bool, suppressIdInfo :: Bool, suppressCoercions :: Bool, pprCaseAsLet :: Bool, pprShowTicks :: Bool, suppressTypeApplications :: Bool, sccProfilingOn :: Bool, } }}} I have a patch in-progress which factors this out, but I want to get some sign-offs that this is a good refactoring before I finish it. The most annoying bits are pretty-printing in the code generator, where all of the platform constants (e.g. word-size) are necessary to print the right way. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 01:52:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 01:52:10 -0000 Subject: [GHC] #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.458f4a6772465f8a722b04fed4b46c49@haskell.org> #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Replying to [comment:9 erikd]: > It seems the 64 bit primpos are *only* needed on 32 bit architectures and then only for the native code generators. Correction, the 64 bit primops are *not* needed on 32 bit architectures because there is currently no way to call them from Haskell code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 03:26:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 03:26:08 -0000 Subject: [GHC] #10144: Variant of runGhc which accepts prelude for setting up DynFlags Message-ID: <045.4a2d86b741cc9cd754eb4aa8764960f3@haskell.org> #10144: Variant of runGhc which accepts prelude for setting up DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- One of the long-standing awkwardness of using the GHC API is the need to call `setSessionDynFlags` *again* after you finish setting up the DynFlags with all the parameters you care about. Furthermore, you must run `getSessionDynFlags` AGAIN in order to get the "most up-to-date" version of `DynFlags`, because the package initialization process twiddles with values in `DynFlags`. That's terrible. What we would like to do is set an invariant that there will be NO non- user changes to DynFlags. That means `pkgDatabase`, `pkgState` and `thisPackage`, which are twiddled by `initPackages`, really *ought not* to live in `DynFlags`. This would also fix a pile of nattering about with copying these values between the interactive DynFlags and normal DynFlags. However, there is a problem with trying to do this: most of the functions in `Packages` assume only a `DynFlags` is available. And you can basically assume that you'll have a `DynFlags` everywhere; not so much for `HscEnv`. So actually fixing this would require a lot of code heaving around that I'm not too interested in at the moment. There is, however, something we can do that will make people's life's better: a new version of `runGhc` which also accepts a function from `GhcMonad m => DynFlags -> m DynFlags` which is responsible for taking the `DynFlags` and configuring it to some suitable state. Whatever is returned, GHC can then make the final modifications (e.g. filling in those fields) and finally setting it as the DynFlags in the HscEnv, and ALSO updating the unsafe global DynFlags. This is not too hard to do. But is it the right thing to do? I'd like to know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 03:27:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 03:27:04 -0000 Subject: [GHC] #10144: Variant of runGhc which accepts prelude for setting up DynFlags In-Reply-To: <045.4a2d86b741cc9cd754eb4aa8764960f3@haskell.org> References: <045.4a2d86b741cc9cd754eb4aa8764960f3@haskell.org> Message-ID: <060.9bd0fc209b82cff599a4110259a68cad@haskell.org> #10144: Variant of runGhc which accepts prelude for setting up DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * component: Compiler => GHC API -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 04:35:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 04:35:30 -0000 Subject: [GHC] #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide In-Reply-To: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> References: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> Message-ID: <060.95532831b57573ed31f18a07a1cae9ab@haskell.org> #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dterei): Thomas, thanks for this, it's great feedback! I'll take a pass over the docs again and incorporate your notes. Some answers: > But isn't the latter implied by the former, or the module wouldn't compile? If that is correct, please mention it. Yes, it is. The description of the check here doesn't distinguish between the fact that some of the check already occurred at compile time and so the recursive element is already done. I'll try to better capture that without removing the description of the check being recursive / transitive. [[BR]] > Should explicitly be implicitly? I don't understand this sentence regardless. What does nicely unifies mean? Yes, I think it should be implicitly. That sentence should probably just be removed. Basically what it is saying is that we ran into a problem when designing Safe Haskell of how to have it co-exists with the existing language in a way that people who care can opt into with all the properties and power we wanted, while users who don't care can ignore the whole thing. In the first version, we got this wrong and Safe Haskell caused compilation failures for people who weren't explicitly using it. The `-fpackage-trust` flag changed to fix this. So really, this line is an off-hand comment on some history that adds no value to the reader. [[BR]] > I think the following statement should be true, but I'm not sure: "If a module M in a package P is inferred to be Safe by GHC, then it is trusted by client C". No, not unconditionally. It depends on `-fpackage-trust`. "M" may be inferred safe, but when GHC does this it assumes that the client "C" is prepared to trust all packages containing `Trustworthy` modules that "M" depends on. It's then up to "C" on her respective system to make that dynamic decision. [[BR]] > I have more of a general question about this: if this is true, then why are there over 200 mentions of {-# Language Safe #-} in a checkout of ghc? Two reasons: 1) Historical -- we added safe inference later. 2) Stability -- one issue with safe inference is that since the module author hasn't stated her intentions, then what Safe Haskell type the module should have isn't set and could change without warning from the compiler. For some library authors this may be fine as Safe Haskell isn't of primary importance to them. But for very base libraries like the ones GHC distributes, we want them to have a very set and stable Safe Haskell type that the community can depend on. The other issue is that using Safe Haskell explicitly adds another dependency that could cause your module to fail to compile. For base modules in GHC this isn't an issue as they have few dependencies and one team largely controls them all. For a higher level package though, use `Safe` explicitly means you are dependent on how the safety of your dependencies change over time. Maybe this is what you want, but for a lot of people where Safe Haskell is a secondary concern, probably not. So it's a trade-off on what concerns and dependencies you have in regards to the larger Haskell community. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 04:42:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 04:42:22 -0000 Subject: [GHC] #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide In-Reply-To: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> References: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> Message-ID: <060.fb6858eb37a3b639bad4f7b81bc3d89f@haskell.org> #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dterei): * owner: => dterei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 06:30:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 06:30:19 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.bd8a094ad73c48aadee7e95fcd7b6457@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by ekmett): FWIW- This started breaking some pre-existing code: https://hackage.haskell.org/package/semigroupoids-1.2.6/docs/src/Data- Functor-Alt.html#some Would having `FlexibleContexts` imply `ConstrainedClassMethods` as well also be too much to ask? Otherwise I'm going to have to start putting CPP around the set of directives for the module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 10:36:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 10:36:17 -0000 Subject: [GHC] #10113: Re-export (<$>) from Prelude In-Reply-To: <042.94e62203b187cd4423f8632566f19490@haskell.org> References: <042.94e62203b187cd4423f8632566f19490@haskell.org> Message-ID: <057.188ba7a6bc90309b55c723ce9e7f97d5@haskell.org> #10113: Re-export (<$>) from Prelude -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.10.1 Component: libraries/base | Version: 7.10.1-rc2 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | report-impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4834 | Test Case: | Blocking: | Differential Revisions: Phab:D680 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"eb3661f2b9f8472f3714774126ebe1183484dd85/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="eb3661f2b9f8472f3714774126ebe1183484dd85" Re-export `<$>` from Prelude (#10113) Whether to re-export the `<$>` non-method operator from `Prelude` wasn't explicitly covered in the original AMP proposal[1], but it turns out that not doing so forces most code that makes use of applicatives to import `Data.Functor` or `Control.Applicative` just to get that operator into scope. To this end, it was proposed to add `<$>` to Prelude as well[2]. The down-side is that this increases the amount of redundant-import warnings triggered, as well as the relatively minor issue of stealing the `<$>` operator from the default namespace for good (although at this point `<$>` is supposed to be ubiquitous anyway due to `Applicative` being implicitly required into the next Haskell Report) [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal [2]: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D680 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 10:42:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 10:42:19 -0000 Subject: [GHC] #10113: Re-export (<$>) from Prelude In-Reply-To: <042.94e62203b187cd4423f8632566f19490@haskell.org> References: <042.94e62203b187cd4423f8632566f19490@haskell.org> Message-ID: <057.709db5fbf600cddbdb4146b485b8416a@haskell.org> #10113: Re-export (<$>) from Prelude -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.10.1 Component: libraries/base | Version: 7.10.1-rc2 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | report-impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4834 | Test Case: | Blocking: | Differential Revisions: Phab:D680 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"479523f3c37894d63352f1718e06696f3ed63143/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="479523f3c37894d63352f1718e06696f3ed63143" Re-export `<$` from Prelude (#10113) This is a follow-up to eb3661f2b9f8472f3714774126ebe1183484dd85 re-exporting `<$` from `Prelude` as well. Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D681 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 10:46:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 10:46:45 -0000 Subject: [GHC] #10113: Re-export (<$>) and (<$) from Prelude (was: Re-export (<$>) from Prelude) In-Reply-To: <042.94e62203b187cd4423f8632566f19490@haskell.org> References: <042.94e62203b187cd4423f8632566f19490@haskell.org> Message-ID: <057.e41a1944baf1743bdd8d6c39ff3156b5@haskell.org> #10113: Re-export (<$>) and (<$) from Prelude -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.10.1 Component: libraries/base | Version: 7.10.1-rc2 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | report-impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4834 | Test Case: | Blocking: | Differential Revisions: Phab:D680 -------------------------------------+------------------------------------- Comment (by hvr): This was also merged to ghc-7.10 via dc737056fd66f6033cf6b7089a8508b62ab2eeb1 and 8601c74450a2a079ab1a8b67f18b503fae5b057b respectively -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 10:56:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 10:56:23 -0000 Subject: [GHC] #10142: Documentation for Ix is contradictory around minimal definition In-Reply-To: <047.81509fc461e889201e078e22917aaf33@haskell.org> References: <047.81509fc461e889201e078e22917aaf33@haskell.org> Message-ID: <062.afc486c835eb8dcd57d59a3d567b29d2@haskell.org> #10142: Documentation for Ix is contradictory around minimal definition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * owner: ekmett => hvr Comment: so while `range` and `inRange` have no default implementation, `index` has one that is recursive: {{{#!hs -- Must specify one of index, unsafeIndex -- 'index' is typically over-ridden in instances, with essentially -- the same code, but using indexError instead of hopelessIndexError -- Reason: we have 'Show' at the instances {-# INLINE index #-} -- See Note [Inlining index] index b i | inRange b i = unsafeIndex b i | otherwise = hopelessIndexError unsafeIndex b i = index b i }}} So the minimal pragma should specify that we minimally need {{{ range && inRange && (index || unsafeIndex) }}} I'll make a patch rightaway... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 11:03:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 11:03:33 -0000 Subject: [GHC] #10142: Documentation for Ix is contradictory around minimal definition In-Reply-To: <047.81509fc461e889201e078e22917aaf33@haskell.org> References: <047.81509fc461e889201e078e22917aaf33@haskell.org> Message-ID: <062.025293c6a67a5c176bab64299fb36017@haskell.org> #10142: Documentation for Ix is contradictory around minimal definition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D709 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D709 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 11:03:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 11:03:50 -0000 Subject: [GHC] #10142: Documentation for Ix is contradictory around minimal definition In-Reply-To: <047.81509fc461e889201e078e22917aaf33@haskell.org> References: <047.81509fc461e889201e078e22917aaf33@haskell.org> Message-ID: <062.b48325a33b7ceb8d003cd5632eb5da84@haskell.org> #10142: Documentation for Ix is contradictory around minimal definition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D709 -------------------------------------+------------------------------------- Changes (by hvr): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 16:30:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 16:30:32 -0000 Subject: [GHC] #10145: :info (->) should list its fixity Message-ID: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> #10145: :info (->) should list its fixity -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The GHC manual states: > * Function arrow is `infixr` with fixity 0. (This might change; I'm not sure what it should be.) Since this isn't the default `infixl 9`, it should be listed when you do `:info (->)`, but currently (at least in 7.8.3) isn't. (Inspired by [http://stackoverflow.com/questions/28916291/associativity- of/28916978#28916978 this Stackoverflow question].) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 16:38:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 16:38:45 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.7b07b9c1b76ff8b6e4c9e217203e11b6@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"b359c886cd7578ed083bcedcea05d315ecaeeb54/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b359c886cd7578ed083bcedcea05d315ecaeeb54" Custom `Typeable` solver, that keeps track of kinds. Summary: This implements the new `Typeable` solver: when GHC sees `Typeable` constraints it solves them on the spot. The current implementation creates `TyCon` representations on the spot. Pro: No overhead at all in code that does not use `Typeable` Cons: Code that uses `Typeable` may create multipe `TyCon` represntations. We have discussed an implementation where representations of `TyCons` are computed once, in the module, where a datatype is declared. This would lead to more code being generated: for a promotable datatype we need to generate `2 + number_of_data_cons` type-constructro representations, and we have to do that for all programs, even ones that do not intend to use typeable. I added code to emit warning whenevar `deriving Typeable` is encountered--- the idea being that this is not needed anymore, and shold be fixed. Also, we allow `instance Typeable T` in .hs-boot files, but they result in a warning, and are ignored. This last one was to avoid breaking exisitng code, and should become an error, eventually. Test Plan: 1. GHC can compile itself. 2. I compiled a number of large libraries, including `lens`. - I had to make some small changes: `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance 3. I also run some code that uses `syb` to traverse a largish datastrucutre. I didn't notice any signifiant performance difference between the 7.8.3 version, and this implementation. Reviewers: simonpj, simonmar, austin, hvr Reviewed By: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D652 GHC Trac Issues: #9858 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 17:15:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 17:15:22 -0000 Subject: [GHC] #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself In-Reply-To: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> References: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> Message-ID: <064.c94f956116f2a2368336e4203a0b3d40@haskell.org> #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: test Operating System: Unknown/Multiple | framework makefile Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D705 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"504d8a4b183670830093a81d3c7a6d78416aed20/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="504d8a4b183670830093a81d3c7a6d78416aed20" Don't assume tools are in same directory as ghc in some cases Summary: Tools such as `ghc-pkg` and `runghc` are no longer required to be in the same directory as `ghc` when running tests, provided that `TEST_HC` is not explicitly set and an in-tree compiler is not used. Fixes #10126. Reviewers: thomie, austin Reviewed By: thomie, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D705 GHC Trac Issues: #10126 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 17:15:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 17:15:22 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.dd18871763be9ff755d8ccb5934ab79f@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D637 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"76b1e11943d794da61d342c072a783862a9e2a1a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="76b1e11943d794da61d342c072a783862a9e2a1a" Improve core linter so it catches unsafeCoerce problems (T9122) Summary: This is a draft of the patch that is sent for review. In this patch required changes in linter were introduced and actual check: - new helper function: primRepSizeB - primRep check for floating - Add access to dynamic flags in linter. - Implement additional lint rules. Reviewers: austin, goldfire, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D637 GHC Trac Issues: #9122 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 17:15:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 17:15:22 -0000 Subject: [GHC] #10058: Panic: Loading temp shared object failed In-Reply-To: <047.df96ee90c5cc42a1abdc47b2157e041f@haskell.org> References: <047.df96ee90c5cc42a1abdc47b2157e041f@haskell.org> Message-ID: <062.f8ab92b3490833874e87c729786837b0@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Runtime System | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10110 | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"0fcc454329c4e3e0dc4474412bff599d0e9bdfcd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0fcc454329c4e3e0dc4474412bff599d0e9bdfcd" Dynamically link all loaded packages in new object Summary: As a result of fixing #8935 we needed to open shared libraries with RTLD_LOCAL and so symbols from packages loaded earlier cannot be found anymore. We need to include in the link all packages loaded so far. This fixes #10058 Test Plan: validate Reviewers: hvr, simonmar, austin Reviewed By: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D676 GHC Trac Issues: #10058 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 17:15:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 17:15:22 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.291c85c3e6fa3043781cc6e093c28eb8@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9186, #9480 | Blocking: | Differential Revisions: Phab:D349 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"0fcc454329c4e3e0dc4474412bff599d0e9bdfcd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0fcc454329c4e3e0dc4474412bff599d0e9bdfcd" Dynamically link all loaded packages in new object Summary: As a result of fixing #8935 we needed to open shared libraries with RTLD_LOCAL and so symbols from packages loaded earlier cannot be found anymore. We need to include in the link all packages loaded so far. This fixes #10058 Test Plan: validate Reviewers: hvr, simonmar, austin Reviewed By: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D676 GHC Trac Issues: #10058 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 17:17:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 17:17:06 -0000 Subject: [GHC] #10058: Panic: Loading temp shared object failed In-Reply-To: <047.df96ee90c5cc42a1abdc47b2157e041f@haskell.org> References: <047.df96ee90c5cc42a1abdc47b2157e041f@haskell.org> Message-ID: <062.a82964ffddbd25c681d7dd5cf5188b72@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Runtime System | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10110 | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 17:17:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 17:17:43 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.183899ff858c25b4a5fcbd9fc0d39fbb@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 17:22:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 17:22:23 -0000 Subject: [GHC] #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself In-Reply-To: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> References: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> Message-ID: <064.6c6c975c74870e3b4d3cc458f0d3c81f@haskell.org> #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.8.4 Resolution: fixed | Keywords: test Operating System: Unknown/Multiple | framework makefile Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D705 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 17:30:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 17:30:29 -0000 Subject: [GHC] #10113: Re-export (<$>) and (<$) from Prelude In-Reply-To: <042.94e62203b187cd4423f8632566f19490@haskell.org> References: <042.94e62203b187cd4423f8632566f19490@haskell.org> Message-ID: <057.2c61d20632af306dc32eba1e16b67de3@haskell.org> #10113: Re-export (<$>) and (<$) from Prelude -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: merge Priority: highest | Milestone: 7.10.1 Component: libraries/base | Version: 7.10.1-rc2 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | report-impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4834 | Test Case: | Blocking: | Differential Revisions: Phab:D680 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 19:45:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 19:45:51 -0000 Subject: [GHC] #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` In-Reply-To: <042.122e93bc881743490b8e64ec2198c257@haskell.org> References: <042.122e93bc881743490b8e64ec2198c257@haskell.org> Message-ID: <057.745ba242f7ddfb39635aefa8e811b7e1@haskell.org> #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9111 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"47b5b5c2b2c92ba091313c36489588edadceaa9d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="47b5b5c2b2c92ba091313c36489588edadceaa9d" base: drop redundant Typeable derivings Thanks to #9858 `Typeable` doesn't need to be explicitly derived anymore. This also makes `AutoDeriveTypeable` redundant, as well as some imports of `Typeable` (removal of whose may be beneficial to #9707). This commit removes several such now redundant use-sites in `base`. Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D712 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 19:45:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 19:45:51 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.22a9af77e3773edc130b5527e9495664@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"47b5b5c2b2c92ba091313c36489588edadceaa9d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="47b5b5c2b2c92ba091313c36489588edadceaa9d" base: drop redundant Typeable derivings Thanks to #9858 `Typeable` doesn't need to be explicitly derived anymore. This also makes `AutoDeriveTypeable` redundant, as well as some imports of `Typeable` (removal of whose may be beneficial to #9707). This commit removes several such now redundant use-sites in `base`. Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D712 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 22:03:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 22:03:28 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.ba8b9894864bc200d945eefb15229554@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:16 ekmett]: > Otherwise I'm going to have to start putting CPP around the set of directives for the module. Why CPP? Afaik, `{-# LANGUAGE ConstrainedClassMethods #-}` is supported since GHC 7.0.1 ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 22:09:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 22:09:19 -0000 Subject: [GHC] #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` In-Reply-To: <042.122e93bc881743490b8e64ec2198c257@haskell.org> References: <042.122e93bc881743490b8e64ec2198c257@haskell.org> Message-ID: <057.44b11d1e788734f1c6fd403d5006d624@haskell.org> #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: wontfix | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9111 #9858 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => wontfix * related: #9111 => #9111 #9858 Comment: this ticket has been rendered unecessary by #9858 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 22:15:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 22:15:31 -0000 Subject: [GHC] #10142: Documentation for Ix is contradictory around minimal definition In-Reply-To: <047.81509fc461e889201e078e22917aaf33@haskell.org> References: <047.81509fc461e889201e078e22917aaf33@haskell.org> Message-ID: <062.812a9d1fe3e454a29e921e349d322b15@haskell.org> #10142: Documentation for Ix is contradictory around minimal definition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D709 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"7a2d65a4d93273c89fbb1d19e282d5933c67c7ca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7a2d65a4d93273c89fbb1d19e282d5933c67c7ca" Define proper `MINIMAL` pragma for `class Ix` Summary: This addresses #10142 Reviewers: goldfire, austin, ekmett Reviewed By: austin, ekmett Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D709 GHC Trac Issues: #10142 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 7 22:20:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Mar 2015 22:20:06 -0000 Subject: [GHC] #10142: Documentation for Ix is contradictory around minimal definition In-Reply-To: <047.81509fc461e889201e078e22917aaf33@haskell.org> References: <047.81509fc461e889201e078e22917aaf33@haskell.org> Message-ID: <062.820a0b8cb51da19faaa53be656255c67@haskell.org> #10142: Documentation for Ix is contradictory around minimal definition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D709 -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: landed to ghc-7.10 via 0d586136ce995f725bcaae064c98298d391ba178 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 00:20:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 00:20:23 -0000 Subject: [GHC] #10146: Clang CPP adds extra newline character Message-ID: <049.7d16de83828bec74f9ab166d6dbd4393@haskell.org> #10146: Clang CPP adds extra newline character -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: cpp | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Running the following command (taken from the settings file) {{{ cat ImportsSemi.hs | gcc -E -undef -traditional -Wunicode -Wno-invalid-pp- token -Wno-unicode - > out.hs }}} on any file results in a file which has an extra newline character appended to the end. This result is different from when `gcc` is used as the preprocessor, in this case no extra newline is appended. I appreciate that this isn't important to most users but it is important for ghc-exactprint. With the extra newline character the EOF marker is moved one line further down. When we come to output the AST, we also get an extra newline at the bottom of the file which breaks roundtripping. {{{ > gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 00:20:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 00:20:50 -0000 Subject: [GHC] #10147: Clang CPP adds extra newline character Message-ID: <049.7bd77bbf9290cdb6b1d3609e1d6c0fc0@haskell.org> #10147: Clang CPP adds extra newline character -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: cpp | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Running the following command (taken from the settings file) {{{ cat ImportsSemi.hs | gcc -E -undef -traditional -Wunicode -Wno-invalid-pp- token -Wno-unicode - > out.hs }}} on any file results in a file which has an extra newline character appended to the end. This result is different from when `gcc` is used as the preprocessor, in this case no extra newline is appended. I appreciate that this isn't important to most users but it is important for ghc-exactprint. With the extra newline character the EOF marker is moved one line further down. When we come to output the AST, we also get an extra newline at the bottom of the file which breaks roundtripping. {{{ > gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 04:46:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 04:46:59 -0000 Subject: [GHC] #10114: Kind mismatches with AnyK in rank-2 types In-Reply-To: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> References: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> Message-ID: <057.230af9f8613a475be77b413a0c25fe1d@haskell.org> #10114: Kind mismatches with AnyK in rank-2 types -------------------------------------+------------------------------------- Reporter: cam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I'm not sure I understand comment:3. What are you worried about? I will also say that it's possible the right answer is {{{ type T = forall k1. (f :: k1 -> *) (a :: k1). f a }}} so that `T :: *`. My understanding is that it's generally more common to restrict the body of a forall to have kind `*`. GHC doesn't do this, but all the papers about System FC do. In other work, I changed the typing rule for forall accordingly, and something broke horribly (eta-reducing newtypes, maybe?), but perhaps we don't have to infer a type that has a non-`*` kind as the body of a forall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 04:48:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 04:48:32 -0000 Subject: [GHC] #10121: operational semantics is incomplete? In-Reply-To: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> References: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> Message-ID: <060.5748a857cf4732cca871316c79bee403@haskell.org> #10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Emails back and forth with the poster indicate that this is harder than I thought. That person is working on it, and I will wait to hear back. Once we have a way forward, I'm happy to update the spec accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 05:32:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 05:32:50 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.db4d8dc53e0eadcae920697b8c55f739@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: This is by design. As I discovered en route to the solution to #9200, the old kind inference for closed type families was bogus. For the type family above, what should the return kind be? `k`, `k2`, and `*` are all viable options. Thus, this type family has no principal kind and should be rejected. Another was of looking at this is that `G` does not have a CUSK. Therefore, its right-hand side must use kind variables uniformly -- which it doesn't, because the first two equations must specialize `k` to `*`. So, closing as invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 05:36:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 05:36:38 -0000 Subject: [GHC] #10143: Separate PprFlags (used by Outputable) from DynFlags In-Reply-To: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> References: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> Message-ID: <060.8b4b7bfbafea4c66ab3867ef95ab1820@haskell.org> #10143: Separate PprFlags (used by Outputable) from DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Just to avoid radio silence: I'm ambivalent about this change. If you see a nice benefit, that's fine for me. But if it doesn't happen, that's fine, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 05:44:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 05:44:41 -0000 Subject: [GHC] #10145: :info (->) should list its fixity In-Reply-To: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> References: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> Message-ID: <060.5b797c656221fc198d81a27de7ce05fa@haskell.org> #10145: :info (->) should list its fixity -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 08:14:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 08:14:28 -0000 Subject: [GHC] #10146: Clang CPP adds extra newline character In-Reply-To: <049.7d16de83828bec74f9ab166d6dbd4393@haskell.org> References: <049.7d16de83828bec74f9ab166d6dbd4393@haskell.org> Message-ID: <064.2ff5e8c5747c6bb0931b8340e0d24c7c@haskell.org> #10146: Clang CPP adds extra newline character -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 08:43:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 08:43:13 -0000 Subject: [GHC] #1831: reify never provides the declaration of variables In-Reply-To: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> References: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> Message-ID: <059.fa5676cf2b7cbd0a2f4ed630b9d02c3f@haskell.org> #1831: reify never provides the declaration of variables -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tomberek): * cc: tomberek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 14:38:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 14:38:19 -0000 Subject: [GHC] #10147: Clang CPP adds extra newline character In-Reply-To: <049.7bd77bbf9290cdb6b1d3609e1d6c0fc0@haskell.org> References: <049.7bd77bbf9290cdb6b1d3609e1d6c0fc0@haskell.org> Message-ID: <064.31357d98d0dc269341cbbfc665ab4296@haskell.org> #10147: Clang CPP adds extra newline character -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Same as #10146. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 14:58:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 14:58:52 -0000 Subject: [GHC] #10146: Clang CPP adds extra newline character In-Reply-To: <049.7d16de83828bec74f9ab166d6dbd4393@haskell.org> References: <049.7d16de83828bec74f9ab166d6dbd4393@haskell.org> Message-ID: <064.97954ca0dfe5290df7b55af6191d37e0@haskell.org> #10146: Clang CPP adds extra newline character -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: How is this a GHC issue? That is, what change to GHC would you like to see here? It sounds like you would like clang's CPP to be "fixed", but I don't think it is really buggy, since the semantics of CPP are defined in terms of tokenized C programs, and adding a trailing newline does not change that tokenization. So, I would not be too hopeful about submitting a bug report, but you could try. I also don't really understand what you are trying to do at all here, isn't the CPP phase quite irreversible regardless of this trailing newline issue? Could you go into more detail about your use case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 15:37:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 15:37:46 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.1c1f9aa394d03fad03b5e0aa2ceb8b07@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317, #9159 | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #9157, #8326, #8317 => #9157, #8326, #8317, #9159 Comment: Also see the comments of #9159. > The case of enumeration types will be reduced to word literals, and treated the same from now on. Note that when matching on an enumeration type, we can assume that the constructor tag is within the range of possible tag values. We cannot make any such assumption for matches on ints. So, we should remember the extra information that we have about the range when doing this reduction. I imagine you will have a function to generate code for an int pattern match with known bounds anyways, as part of a binary search algorithm, so this should not complicate the code greatly. > Matching against literals literals is fishy anyways, so my suggestion is to simply generate a linear list of equality checks here ? turning the intended operation (equality test) into something else (comparisons in a if-then-else tree) feels wrong to me for floats. I don't see anything wrong with using comparisons for pattern matching on floats as long as the patterns are all finite numbers (though there is trickiness around negative zero to be aware of). But I also think float pattern matching is much less important than your other goals, so I would agree with doing something simple for floats, at least initially. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 15:37:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 15:37:56 -0000 Subject: [GHC] #9159: cmm case, binary search instead of jump table In-Reply-To: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> References: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> Message-ID: <063.bdce967ccaeaa2534282f36ec7cfc6f4@haskell.org> #9159: cmm case, binary search instead of jump table -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: feature request | Status: new Priority: lowest | 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: #10137 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #10137 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 16:14:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 16:14:59 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.f9c842495433f22584eb0209399ad6fa@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317, #9159 | -------------------------------------+------------------------------------- Comment (by nomeata): > Note that when matching on an enumeration type, we can assume that the constructor tag is within the range of possible tag values. We cannot make any such assumption for matches on ints. So, we should remember the extra information that we have about the range when doing this reduction. Right. The datatype is currently {{{ data SwitchTargets = SwitchTargets (Maybe (Integer, Integer)) (Maybe Label) (M.Map Integer Label) }}} so there optionally is a definite range (absent when matching literal). The function `addRange` in the new `CmmSwitch` module (currently in branch `wip/T10137`) takes care of that case, before the general layout algorithm runs on the remaining range. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 16:23:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 16:23:04 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.564c34f6b60c74a198b0cd195bca1a1b@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: dreixel => * status: merge => new Comment: (Reopening for discussion) Sorry for getting here a bit late; but I have some concerns about this change as it stands currently. Abstractly my main concern is that we've made a change (implicitly deriving Typeable everywhere) for the wrong reasons, and concretely my main fear, given the timing of this change, is that we'll find the new approach is untenable for some reason or other and be forced back into a world in which explicit deriving Typeable is required. I'm certainly not trying to say that implicitly deriving Typeable is the wrong decision; but it seems that it arose as fallout from the issue in this ticket and #10000 for technical reasons, and not because we decided that we really want it. We will always be able to transition to implicit deriving Typeable in the future, but transitioning back to explicit deriving Typeable loses compatibility with programs written for an earlier version of the compiler that had implicit deriving Typeable. So, seeing as we are in the RC phase for 7.10, my recommendation would be: - Keep the requirement to explicitly derive Typeable (and keep AutoDeriveTypeable, etc.) as in 7.10 RC 2 - Don't actually generate evidence terms when deriving Typeable. Instead mark the type as "Typeable-allowed". - When generating evidence in the Typeable solver, check that all of the types involved are marked as "Typeable-allowed". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 16:31:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 16:31:08 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.54288a108c604301a305215298e8bfef@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): In this particular case, given the third equation `G a = a`, I'm pretty sure the only possible return kind is `k`, no? But there was that whole long discussion about CUSKs that I didn't really follow, so I take it that in general a closed type family may have no principal kind. I would venture to say though that the error message GHC produces is IMHO not that helpful. In this case the fix is clearly to add a CUSK `type family G (a :: k) :: k where`; could GHC work out when it is appropriate to suggest adding a CUSK? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 16:47:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 16:47:58 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.84fea254512fc944a92ed0dd56c443c8@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: Presumably, if this is a GHC issue and not a clash issue (okay, seems likely!) then there is some input file that clash provides to ghc which would exhibit this behavior. dongen, since you are the one who knows about clash, could you extract this file? Or, if clash is instead a GHC API consumer, then it may require more clash expertise to figure out exactly what input is being provided to GHC. Probably all it takes is extracting the definitions of all those type families from wherever they are defined by clash; but in any case we need a test case for GHC, and you as the clash user are best situated to provide it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 17:56:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 17:56:58 -0000 Subject: [GHC] #8780: abs for IEEE floating point is slightly wrong. In-Reply-To: <047.7d758a25f9194c7d9c9382206575054a@haskell.org> References: <047.7d758a25f9194c7d9c9382206575054a@haskell.org> Message-ID: <062.86cba343a55072276c5eb5558beed8f3@haskell.org> #8780: abs for IEEE floating point is slightly wrong. -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7858 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:2 augustss]: > It seems the printing of -0 has changed. Here's my session > > {{{ > $ ghci > GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> let x = -0 > Prelude> x > 0 > }}} This part is just because `x` defaulted to Integer on this line; `-0.0` is still printed as `-0.0`. (7.8.3 has the MR disabled in ghci by default.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 17:58:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 17:58:28 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.324edbcdf1d5046a9896d83c04983bf5@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: goldfire => * status: closed => new * resolution: invalid => Comment: Replying to [comment:2 goldfire]: > So, closing as invalid. I believe we should create a test case so that any accidental change of semantics does not go unnoticed (like it seems to have between 7.8.3 and 7.10.1?). Richard, I'm re-opening and assigning to you but if you don't have the time please re-assign it to me - I'll take care of that in due time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 17:58:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 17:58:50 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.e42dd0be7de86daf0ea6197b5f2605ee@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 18:02:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 18:02:09 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.146ef4aae89087139e3cda7e5d6cb3c9@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: rwbarton => Comment: No, I'm not actively working on this and I don't intend to in the near future. Are you planning to just rewrite ghc-split in Haskell, or to change its interface in some way? If the latter, could you describe the changes you plan to make here so I can comment on whether they would be suitable for the LLVM backend also? No point in redesigning twice. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 18:04:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 18:04:38 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.75084609af5cef54bab0a82d49f50930@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * owner: => simonmar * component: GHCi => Runtime System Comment: I can reproduce the notorious 'ioManagerWakeup' bug. Not for `ghci004` itself, but for some other ghci tests. On my puny laptop with only 2 cores, I do the following: 1. Make sure the cpu is plenty busy, by running `ghc -e [0..] > /dev/null` in 3 different shells. 2. Run `make test EXTRA_HC_OPTS='+RTS -I0.1 -RTS' TEST='print002 print003 print006 print007 print008 print010'` For me, all tests always fail with: "ioManagerWakup: write: Bad file descriptor" Step 2 sets the 'GC idle time' for ghci script tests to 0.1 seconds (from the default for GHC/GHCi of 5 seconds, see #3408); the same value that is used for other tests with WAY=ghci (among which `ghci004`). The necessity of step 1 might explain why we don't see the bug when running a single test in isolation, but only when running validate, which runs a lot of tests at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 18:13:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 18:13:39 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.3ce0a85cd31c6f3455c46a215fc1182f@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D714 Comment: I have a workaround patch which sets the 'GC idle time' for ghci tests to 0.3 seconds, which is the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime- control.html#rts-options-gc default] for user programs. This prevents the bug from triggering. We can keep this ticket open until the real bug is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 18:46:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 18:46:35 -0000 Subject: [GHC] #4372: Extending quasiquotation support In-Reply-To: <046.070081740d53fd2b18d950319658559f@haskell.org> References: <046.070081740d53fd2b18d950319658559f@haskell.org> Message-ID: <061.8d15728e0b7d4fef0084a42349aa8a41@haskell.org> #4372: Extending quasiquotation support -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): songzh: `'[' quoterExp '|' strings '|]'` is not really possible since it looks too much like any list comprehension. If you wrote `[ x * y | x <- [1,2,3], y <- [4,5] ]` is that a list comprehension or the beginning of a quasiquote, that might terminate arbitrarily far away? With quasiquotes as they stand now you cannot write a list comprehension like `[x|x<-[1,2,3]]`; you must include a non-identifier character before the `|`. That's a mild imposition, but it is already something, and I don't see how the syntax can be pushed much farther. As for the ticket in general: Quasiquotes offer two conveniences over TH splices: overloading the same name to refer to expression, pattern, etc. splice generators; and raw string literals (terminated by `|]`). The overloading can be nice, but is never essential (the resolution is purely syntactic anyway) and often you only need the expression quoter. The raw string literal syntax is quite useful, but it's a problem that only needs to be solved once. Specifically, once you have a quasiquoter `q` that produces string literals, you can rewrite any {{{ [foo|bar|] }}} as {{{ $(foo [q|bar|]) -- this 'foo' is the old 'quoteExp foo'. -- at worst, you could call it 'fooE' or something. }}} which is already not that much longer; and any syntax for parameterized quasiquoters would have to be longer than `[foo arg|bar|]`, so there's very little room left for improvement over what we can build with the pieces we have today. So basically I agree with Gershom: the workaround he suggested is always possible, it's pretty lightweight, and it's hard to see how a new syntax for this would really be worth it, when it can't gain much (and has the opportunity cost of not being able to use the syntax for something else). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 18:56:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 18:56:31 -0000 Subject: [GHC] #10081: SIGTERM ignored when process has been detached from terminal In-Reply-To: <044.1f8bc4458608289c276bfd2ddfa7272f@haskell.org> References: <044.1f8bc4458608289c276bfd2ddfa7272f@haskell.org> Message-ID: <059.c04136f2ad53eafb83abc0bd4e7889dd@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): nakal: consider this program for instance {{{ import Control.Concurrent import Control.Exception import Control.Monad import System.Exit import System.IO import System.Posix.Signals loop = forever $ threadDelay 1000000 main = do ppid <- myThreadId mapM (\sig -> installHandler sig (Catch $ trap ppid) Nothing) [ keyboardSignal ] loop trap tid = do hPutStrLn stderr "Signal received.\n" throwIO Overflow throwTo tid ExitSuccess }}} If you run it in a terminal and press ctrl-C, you will see {{{ ^CSignal received. u: arithmetic overflow }}} and the program will keep running. ---- To catch the exception from `hPutStrLn` you can simply do {{{ import Control.Exception import Control.Concurrent import Control.Monad import System.Exit import System.IO import System.Posix.Signals loop = forever $ threadDelay 1000000 main = do ppid <- myThreadId mapM (\sig -> installHandler sig (Catch $ trap ppid) Nothing) [ lostConnection, keyboardSignal, softwareTermination, openEndedPipe ] loop trap tid = do let handler :: SomeException -> IO () handler _ = return () catch (hPutStrLn stderr "Signal received.\n") handler throwTo tid ExitSuccess }}} and now the program exits when run and killed as in your fourth test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 19:13:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 19:13:08 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs (was: Remove Hack in compiler/nativeGen/MachCodeGen.hs) In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.650ad495b003dd96f8d81f9db52e2e5c@haskell.org> #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I would not be surprised if it was better (equal or faster performance and smaller object file size) to use 32-bit offsets anyways, has anyone done a performance test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 19:45:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 19:45:36 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.f7861ced0cbe679158586df62a33fca2@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: #9268 | Differential Revisions: ----------------------------------------+--------------------------------- Comment (by erikd): I've attached an updated version of the patch that I have tested on my own personal armhf build box. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 20:52:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 20:52:49 -0000 Subject: [GHC] #10099: cabal install broken with ghc 7.10.1-rc2 In-Reply-To: <047.602c37795a358463eb57e7ffa8e992ef@haskell.org> References: <047.602c37795a358463eb57e7ffa8e992ef@haskell.org> Message-ID: <062.dc5e7ecf541816898b2fbabb497b681c@haskell.org> #10099: cabal install broken with ghc 7.10.1-rc2 -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Package system | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ttuegel): This Cabal issue was fixed in [https://github.com/haskell/cabal/commit/25f7f9a1389686e3d5083ab36fa90f59ccaa2652 25f7f9a]. 7.10.1-rc2 predates this patch, but this will need to be in the final 7.10.1 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 21:39:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 21:39:23 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.315cdf054984c2a758bea94a79a1e23e@haskell.org> #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: low | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * priority: normal => low Comment: As austin writes in Phab:D694, we are not going to able to change that in the near future anyways. Lowering severity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 22:56:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 22:56:48 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.d37aa57ac3d4682164b8b6a0fb962246@haskell.org> #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: low | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Oh, I see the jump table entries are currently padded to 64 bits anyways. So then it should be slightly better to use a 64-bit relocation instead, but maybe it would be even better to pack the entries into 32 bits instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 23:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 23:00:30 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.b7ee6862a2b6d1301b9285bd913bc444@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by thomie): Smaller test case (without any cpu loading) for the real bug: {{{ $ cat T9722.hs main = return () $ ghc-7.10.0.20150307 -threaded -rtsopts T9722.hs $ ./T9722 +RTS -I0.000000001 T9722: ioManagerWakeup: write: Bad file descriptor }}} This only happens ~50% of the time, and it doesn't happen with 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 23:46:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 23:46:08 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.5387d91779d12a043199f0611181d95b@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): Where is T9722.hs? Is it in master branch somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 8 23:47:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Mar 2015 23:47:24 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.6784bdac98703e43ddf4e521a0145169@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): Replying to [comment:17 AndreasVoellmy]: > Where is T9722.hs? Is it in master branch somewhere? Nevermind. I see the contents of T9722 from your message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 01:20:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 01:20:08 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.bd2ab926ac543895fd4469d90af03b4d@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): I wasn't able to cause the problem with either T9722 with the arguments mentioned above or with the test with print002, etc. I tried with a fresh copy of ghc (version 7.11.20150307). I'll try to create it again with `sh validate --fast`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 02:10:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 02:10:46 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.209927eb56efc611237edd9f461ff235@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by thomie): Andreas: if your computer has more than 2 cores you might need to start more copies of `ghc -e [0..] > /dev/null`. Another good one to keep the cpu is busy is to compile `ghc` with `-j` at the same time. Do all of that, and then run the `print002` test with `+RTS -I`. It should work... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 03:38:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 03:38:41 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.ba38834e156a7a94b0adb4fa8b2dc507@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => highest Comment: If Travis can't test packages, that's pretty bad for GHC. Bumping priority accordingly. I think this should hold up a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 05:23:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 05:23:04 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.90b3700ab67f56f63ba78d016857ec74@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): To clarify comment:64, I understand that this proposal doesn't really change the recent patch under the hood, but just the user interface to it. (Yes, tracking `Typeable`-allowed-ness takes some under-the-hood work.) Please correct me if I'm wrong. I think that having `Typeable` available for every type is the right thing to do. It's something I have wanted for some time. This ticket just made the change happen now instead of soon. All that said, I can understand the worry that we'll paint ourselves into a corner here. It might be reasonable to adopt the proposal above for 7.10 and then relax it for 7.12, when we have more time to see possible strange interactions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 05:30:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 05:30:16 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.50aa1284c16945e95e356f1aaec51384@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Responding to comment:3: No, the return kind could well be `*`. I'll rewrite with explicit kinds: {{{ type family G (a :: k) :: * where G * Int = Bool G * Bool = Int G * a = a }}} This `G` doesn't really use its kind-polymorphism, but the definition kind checks. However, I think you're right about the suggestion for a CUSK, here and in other cases. And I think it's possible for GHC to have at least some heuristics for when a CUSK is the answer. Specifically, it could include a note about CUSKs in error messages that arise from kind mismatches in non- CUSK right-hand sides. And, yes, this would make for a decent test case. Thanks for the suggestion. I'm very unsure I can get to this by Friday (the next RC release), though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 05:30:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 05:30:32 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.e1271ac85084e49cd70e2c04bfe69fb0@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * priority: highest => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 05:30:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 05:30:50 -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.ab41eb8980ed06739a3dbcd5a82f8b8e@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => high Comment: Bumping priority here, as it exposes a hole in Safe Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 06:54:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 06:54:39 -0000 Subject: [GHC] #9863: Provide PowerPC 64 bit native code generator In-Reply-To: <047.abf3d61d6edeed38824d04625109fece@haskell.org> References: <047.abf3d61d6edeed38824d04625109fece@haskell.org> Message-ID: <062.944fc8433985a055e8fbd005aa6b48c1@haskell.org> #9863: Provide PowerPC 64 bit native code generator ------------------------------------+------------------------------------ Reporter: trommler | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D629 ------------------------------------+------------------------------------ Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 09:29:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 09:29:08 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.fc663580392a237d22418a53d57ecfd4@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:64 rwbarton]: > Abstractly my main concern is that we've made a change (implicitly deriving Typeable everywhere) for the wrong reasons, and concretely my main fear, given the timing of this change, is that we'll find the new approach is untenable for some reason or other and be forced back into a world in which explicit deriving Typeable is required. Does artificially keeping require to explicitly derive `Typeable` during the 7.10 cycle actually help us identifying issues, rather than just releasing this into the wild with 7.10 and gather real-world data during 7.10's life-cycle? Fwiw, IIRC we wanted to turn on `AutoDeriveTypeable` by default anyway sooner or later. So this change just accomplishes that by a different mechanism, but the outcome is the same IMO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 10:31:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 10:31:25 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.26583245d2e5e2327c8a3e578b92c205@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): @simon Thanks. I don't have time to work on a minimal example. As I mentioned extracting the cause of the problem already took hours. This is really nasty stuff and there's no quarantee I'll succeed. @rwbarton I already tried copying the definitions and produce an example that doesn't depend on CLaSH. Unfortunately, the example compiled fine. I mentioned this in a previous post. I'll look at `MonoLocalBinds` suggestion later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 11:04:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 11:04:02 -0000 Subject: [GHC] #10148: Optimization causes repeated computation Message-ID: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The attached program, when compiled with `-O0`, calls `array_adjust` 6 times and hence prints 6 lines of trace output. However, with `-O1`, it prints 37 lines of trace output instead. Moreover, this number grows quadratically rather than linearly when I increase the value of `n`. `-fno-state-hack` did not help. I can reproduce the issue with both GHC 7.8.4 and 7.10.0.20150123. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 12:50:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 12:50:09 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.7bb28088358be655420106f18c0fdf08@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): I still haven't been able to recreate this. What OS are you running and can you post which commit of ghc you are working with? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 12:53:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 12:53:29 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.53db50bb944242a8f8c5ad9094f1d4d6@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Fun fact: Most changes make the problem go away. * Changing the `data Array' a = ALeaf a` to a `newtype Array' a = ALeaf a` * not calling `go` in `array_adjust` * adding a `trace` to the pattern matching in `adjustA` * removing the pattern match there completely * removing the Bang Pattern in `gstep` * removing the first parameter from `Array` * marking `mkMaschine` `NOINLINE` Here is a cue: Removing the `!` on `t` in `mkMachine` removes *all* trace output. So it seems that (possibly as a result of minimizing the code), `t` and hence `array_adjust` is not actually used. This (function strict in an argument, but argument is unused) might make GHC be a bit too liberal in what it does with the code. (Didn?t look at Core so far, though). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 13:10:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 13:10:00 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.1e6c7fee168b44da32d001a8992119c8@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by thomie): I am on 64 bit Ubuntu 14.04. I can reproduce with `ghc-7.10.0.20150307` and `ghc-7.11.20150307` from https://launchpad.net/~hvr/+archive/ubuntu/ghc (ghc-head). I have attached the output from running `./T9722 +RTS -I0.0001 -Ds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 13:20:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 13:20:18 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.b1b7703a5c4a46398fc42dfb28e99c74@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It's certainly possible to make it possible ''not'' to have `Typeable`. But it's a significant chunk of extra work, and at the moment we pretty strongly believe we'll want to throw it away anyway. I don't think we have a single example of a situation which having `Typeable` is bad. However, if (against all the evidence) someone eventually produces a situation in which we don't want `Typeable` for some type, we can I suppose implement `NoAutoDeriveTypable`. So I don't think we are painting ourselves into any corners. Reasonable questions, but I think we should proceed as planned. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 13:43:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 13:43:00 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.c81ac94a098ddd6cd1b8df076fa30b76@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): I'll keep trying to reproduce... in the meantime, can you try to recompile ghc with the following definition in rts/posix/Signals.c? Then recreate the bug and we will hopefully have a bit more info to help debug: {{{ void ioManagerWakeup (void) { int r; int fd; // Wake up the IO Manager thread by sending a byte down its pipe if (io_manager_wakeup_fd >= 0) { #if defined(HAVE_EVENTFD) StgWord64 n = (StgWord64)IO_MANAGER_WAKEUP; fd = io_manager_wakeup_fd; r = write(fd, (char *) &n, 8); #else StgWord8 byte = (StgWord8)IO_MANAGER_WAKEUP; fd = io_manager_wakeup_fd; r = write(fd, &byte, 1); #endif if (r == -1) { perror("ioManagerWakeup: write(A)"); sysErrorBelch("ioManagerWakeup: write; fd: %d", fd); } } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:10:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:10:39 -0000 Subject: [GHC] #10149: The argument of mask does not always restore the masking state Message-ID: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> #10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the documentation of `mask` and `uninterruptibleMask` it is claimed that the `restore` argument restores the masking state. However this is not true in the following programs: {{{#!hs mask_ $ -- start with exceptions masked mask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $ restore $ getMaskingState >>= print }}} {{{#!hs uninterruptibleMask_ $ -- start with exceptions uninterruptibly masked uninterruptibleMask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $ restore $ getMaskingState >>= print }}} The expected state is that `getMaskingState` would produce `MaskedInterruptible` and `MaskedUninterruptible`, however, in both cases it gives Unmasked. Either the documentation needs to be changed, or the implementation must really restore the masking state in these cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:11:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:11:27 -0000 Subject: [GHC] #10149: The argument of mask does not always restore the masking state In-Reply-To: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> References: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> Message-ID: <071.13ee9e4aeb8a0dfef8ed29713767b384@haskell.org> #10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: libraries/base | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by facundo.dominguez: Old description: > In the documentation of `mask` and `uninterruptibleMask` it is claimed > that the `restore` argument restores the masking state. However this is > not true in the following programs: > > {{{#!hs > mask_ $ -- start with exceptions masked > mask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $ > restore $ getMaskingState >>= print > }}} > > {{{#!hs > uninterruptibleMask_ $ -- start with exceptions uninterruptibly masked > uninterruptibleMask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $ > restore $ getMaskingState >>= print > }}} > > The expected state is that `getMaskingState` would produce > `MaskedInterruptible` and `MaskedUninterruptible`, however, in both cases > it gives Unmasked. > > Either the documentation needs to be changed, or the implementation must > really restore the masking state in these cases. New description: In the documentation of `mask` and `uninterruptibleMask` it is claimed that the `restore` argument restores the masking state. However this is not true in the following programs: {{{#!hs mask_ $ -- start with exceptions masked mask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $ restore $ getMaskingState >>= print }}} {{{#!hs uninterruptibleMask_ $ -- start with exceptions uninterruptibly masked uninterruptibleMask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $ restore $ getMaskingState >>= print }}} The expected result is that `getMaskingState` would produce `MaskedInterruptible` and `MaskedUninterruptible`, however, in both cases it gives Unmasked. Either the documentation needs to be changed, or the implementation must really restore the masking state in these cases. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:20:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:20:14 -0000 Subject: [GHC] #10143: Separate PprFlags (used by Outputable) from DynFlags In-Reply-To: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> References: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> Message-ID: <060.f3b8154e447725f034d26ccbebb66785@haskell.org> #10143: Separate PprFlags (used by Outputable) from DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'll all for it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:24:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:24:30 -0000 Subject: [GHC] #10144: Variant of runGhc which accepts prelude for setting up DynFlags In-Reply-To: <045.4a2d86b741cc9cd754eb4aa8764960f3@haskell.org> References: <045.4a2d86b741cc9cd754eb4aa8764960f3@haskell.org> Message-ID: <060.e8f7d27bb0affe747ebe456610b22456@haskell.org> #10144: Variant of runGhc which accepts prelude for setting up DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Without looking at this in detail, it smells to me that the pacakge- database stuff should be in `HscEnv` (which embodies the session state) rather than in `DynFlags`. Changing some arguments from `DynFlags` to `HscEnv` doesn't sound so bad. I wonder if the package stuff should be mutable state, rather than returning a new `HscEnv`? Many other things in `HscEnv` have this mutable-state flavour. I feel I don't know enough to have an opinion on the "new version of `runGhc`". Anything that makes the GHC API simpler and more robust is good.# Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:25:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:25:41 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.265313072c9f7af5d916b8155f5d9202@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by simonpj): Herbert's point is a good one. But it would not be impossible to make `FlexibleContext` also imply `ConstrainedClassMethods`, if that was vastly better. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:33:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:33:21 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.278837f1c21616438695eda4158a3903@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by ekmett): It has been around for a long time, but I know at least a few of us were rather startled when we started getting error messages about it and every occurrence I've found so far is a module where I have FlexibleContexts already enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:34:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:34:45 -0000 Subject: [GHC] #10149: The argument of mask does not always restore the masking state In-Reply-To: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> References: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> Message-ID: <071.0dfa87c13a100fe1e4c6970938ca04d6@haskell.org> #10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: libraries/base | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Other failing examples not involving `forkIOWithUnmask`: {{{#!hs mask $ \unmask -> mask $ \restore -> unmask $ restore $ getMaskingState >>= print }}} {{{#!hs uninterruptibleMask $ \unmask -> uninterruptibleMask $ \restore -> unmask $ restore $ getMaskingState >>= print }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:37:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:37:05 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.a18193a4c6d808111a9f2baebca1e060@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by simonpj): Well, bugs (and this was a bug) are like that! It's not so hard, and it is truthful, to add `ConstrainedClassMethods` to those libraries. But if the CLC advises, we can also make `FlexibleContexts` imply it. Remember this is not in 7.10 so libraries have time to adapt. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:37:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:37:48 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.f0a35b92d7d10d4c73d5acdbeccc4cd0@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not particularly concerned about the possibility of this change breaking any existing program; that seems rather unlikely. What I am concerned about is the possibility of another bug like #10000 being discovered that forces us to abandon this "all types are Typeable" approach. It just seems like common sense to me to make large language changes like this at the start of a version's development, not one week before the last release candidate. (And I say large because there are probably tens of thousands of "deriving Typeable" out there. Yes I'd like to get rid of them too, but only if I could be reasonably sure that they won't have to be added back in for 7.10.2!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:42:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:42:31 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.73faa4ec54d75555121c08eec034d776@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Well I can't deny that it's possible. But if it happens, we can fix it, as I outline above. I'd just rather avoid investing effort that we expect to be useless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 14:52:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 14:52:06 -0000 Subject: [GHC] #10114: Kind mismatches with AnyK in rank-2 types In-Reply-To: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> References: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> Message-ID: <057.498e044b64a726108047d39a56dad4a0@haskell.org> #10114: Kind mismatches with AnyK in rank-2 types -------------------------------------+------------------------------------- Reporter: cam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): In comment:3 I think I was confusing these two things: {{{ T = forall k. blah T :: forall k. blah -- Uses of T must be applied to a kind }}} So I think I retract my claim in comment:1. Perhaps we do want to generalise "inside". Can anyone say why it is "generally more common to restrict the body of a forall to have kind `*`"? I can't articulate a clear argument. In GHC's case, a good reason not to do this was types like `forall a. a -> (# a, a #)`, but levity polymorpism will help here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 15:17:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 15:17:18 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.1d1b72216daf60a1221c17d693eb638b@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): In that case perhaps we should advertise the new automatic Typeable deriving behavior as experimental in 7.10, so that users can decide whether they want to rely on it or not. Also, I think it's definitely correct that (as it is currently) warn- deriving-typeable ''not'' be enabled by `-Wall`. We can turn on the warning in 7.12. By the way, we may want to use a similar mechanism of generating evidence at the call site to handle #9557. For that problem, we would certainly need to track whether or not the class was derived at the definition site. So, I don't actually expect the effort to be useless. But the timing may be wrong here, unfortunately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 15:38:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 15:38:45 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.958f7144063e808108eede4bc2687b66@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by thomie): I build a fresh ghc head (commit 8b7534b39052c9cb44411bea0ca311a751564d6c) with the change to `ioManagerWakeup` from comment:23. {{{ $ ~/ghc-master-build/inplace/bin/ghc-stage2 -threaded -rtsopts T9722.hs $ ./T9722 +RTS -I0.000000001 ioManagerWakeup: write(A): Bad file descriptor T9722: ioManagerWakeup: write; fd: 9: Bad file descriptor }}} I don't understand why the output is different when I redirect it to a file. But in case it gives you a clue, here it is: {{{ $ ./T9722 +RTS -I0.000000001 > T9722.stderr $ cat T9722.stderr ioManagerWakeup: write(A): Bad file descriptor T9722: ioManagerWakeup: write; fd: 9: Invalid argument }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 15:49:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 15:49:06 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.04017ed47b59b7a228ef62800aab18e7@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317, #9159 | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata Comment: I?m happy to have some code review on Phab:D720, but it is still work-in- progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 16:41:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 16:41:00 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.5694e534555ff4f0c65136c8f5c8ddd0@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Ben, I see you started working on the implementation. Perhaps it's worth putting it on Phab? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 17:21:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 17:21:27 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.496db7c4b25cc0a31d77aae7c6790c1f@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): Thanks thomie! I think I see what is happening now: the TimerManager registers a file descriptor with the RTS for use by the `ioManagerWakeup()` function in `rts/posix/Signals.c`. When the TimerManager shuts down, it closes this file descriptor. I think there is a race condition where rts/Schedule.c calls `ioManagerWakeup()` after the TimerManager has shutdown. The TimerManager should only shutdown when the program is exiting, so it's probably safe to simply silently ignore the failing write, although this probably needs some review. In the meantime, I've modified `GHC/Event/Control.hs` to write `-1` to `io_manager_wakeup_fd` just before it closes the file descriptor. This should address the race condition. Can you compile your ghc with the attached Control.hs and check whether it makes the problem go away for you? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 18:03:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 18:03:28 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.fd5878db9185899ac751ef7e101714b9@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by thomie): I ran all the tests I mentioned before multiple times, and they all succeeded. Hurray! Before shipping: I did get a build warning about unused `UNPACK` in `W`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 18:11:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 18:11:04 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.0f5a79ddfcf1087750d20bfe9075b94d@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317, #9159 | -------------------------------------+------------------------------------- Description changed by nomeata: Old description: > Inspired by #10124 I looked at the code generation for enumeration and > integer types, and I think this can be improved in a few ways. My goals > are: > > * Fancier code for integer types. Currently, the code for enumeration > types will emit jump tables for dense choices; there is no reason to > treat integer types differently. > * The ability to behave differently if some of the cases are equal, and, > as an extension of that, > * The possibility to create branchless code if multiple checks would go > to the same jump. > > The current scheme is roughly: > > * When we generate Cmm code for a STG case expression, we handle > enumeration types and literals separately. > * At this point, the decisions about what code to generate are made > (jump tables (but only for enumeration types) or if-then-else trees). > * The Common Block Optimization on Cmm happens later in the pipeline, > making it non-trivial to detect branches that do the same thing. > > My plan is the following: > > * In the STG?Cmm transformation, floats will be handled separately. > Matching against literals literals is fishy anyways, so my suggestion is > to simply generate a linear list of equality checks here ? turning the > intended operation (equality test) into something else (comparisons in a > if-then-else tree) feels wrong to me for floats. And the rest would not > work well for floats, so I?d like to have them out of the way. > * The case of enumeration types will be reduced to word literals, and > treated the same from now on. > * For integer types, no code generation decisions is made at this point. > Instead, always a `CmmSwitch` statement is generated. > * In a separate Cmm transformation pass, which will run /after/ the > common block optimization, we visit all `CmmSwitches` and create proper > code for them. > > I?d like to separate the algorithm that plans the code generation into a > function (possibly even module) of its own, so that the decisions can > easily by analyized and modified. > > The algorithm has a few choices to make: > > * If multiple values point to the same code, we can generate branchless > code (`y := x == 1 || x == 5 || x = 7; if (y==0) then goto l1 else goto > l2`). > * If there are whole ranges pointing to the same code, the above can > also use comparisons. > * If there are dense ranges (i.e. a range with more than half of the > possible values mapped to something), we want to generate jump tables > from them (still `CmmSwitch` values). > * Unless all options are handled by one of these possibilities, they > need to be combined using `if-then-else` trees. > > The `CmmSwitch` constructor needs to change for that. It currently takes > a `[Maybe Label]` argument, which is not suitable for before that pass, > when its table may be sparse. I think an `IntMap Label` would work > nicely. New description: Inspired by #10124 I looked at the code generation for enumeration and integer types, and I think this can be improved in a few ways. My goals are: * Fancier code for integer types. Currently, the code for enumeration types will emit jump tables for dense choices; there is no reason to treat integer types differently. * The ability to behave differently if some of the case alternatives are equal, and, as an extension of that, * The possibility to create branchless code if multiple checks would go to the same jump. The current scheme is roughly: * When we generate Cmm code for a STG case expression, we handle enumeration types and literals separately. * At this point, the decisions about what code to generate are made (jump tables (but only for enumeration types) or if-then-else trees). * The Common Block Optimization on Cmm happens later in the pipeline, making it non-trivial to detect branches that do the same thing. My plan is the following: * In the STG?Cmm transformation, floats will be handled separately. Matching against literals is fishy anyways, so my suggestion is to simply generate a linear list of equality checks here ? turning the intended operation (equality test) into something else (comparisons in a if-then- else tree) feels wrong to me for floats. And the rest would not work well for floats, so I?d like to have them out of the way. * The case of enumeration types will be reduced to word literals, and treated the same from now on. * For integer types, no code generation decisions is made at this point. Instead, always a `CmmSwitch` statement is generated. * In a separate Cmm transformation pass, which will run /after/ the common block optimization, we visit all `CmmSwitches` and create proper code for them. I?d like to separate the algorithm that plans the code generation into a function (possibly even module) of its own, so that the decisions can easily by analyized and modified. The algorithm has a few choices to make: * If multiple values point to the same code, we can generate branchless code (`y := x == 1 || x == 5 || x = 7; if (y==0) then goto l1 else goto l2`). * If there are whole ranges pointing to the same code, the above can also use comparisons. * If there are dense ranges (i.e. a range with more than half of the possible values mapped to something), we want to generate jump tables from them (still `CmmSwitch` values). * Unless all options are handled by one of these possibilities, they need to be combined using `if-then-else` trees. The `CmmSwitch` constructor needs to change for that. It currently takes a `[Maybe Label]` argument, which is not suitable for before that pass, when its table may be sparse. I think an `IntMap Label` would work nicely. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 18:43:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 18:43:13 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.eaedc5df2b66c1ef7633b99af2a5ad5e@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): OK great! To summarize: Whenever the RTS has been inactive for idleGCDelayTime, the idle timer fires and calls `wakeUpRts()`, which in turn calls `ioManagerWakeup()`, which in turn writes a byte (or a few) to a file descriptor (stored in the `io_manager_wakeup_fd` variable) registered by the TimerManager and on which the TimerManager will wait. (Note that the write will only occur if the file descriptor is non-negative.) When the RTS shuts down, it shuts down the TimerManager, and in this process the file descriptor stored in `io_manager_wakeup_fd` is closed. In the error case, the idle timer fires after the close of the file occurs, and then the `write()` call in `ioManagerWakeup()` fails and the aforementioned error message gets printed. I think the solution in the Control.hs modification is solid; it addresses the problem without silently ignoring other error conditions due to the `write()`. Another solution might be to disable the idle timer once the program shutdown sequence has started, though that could have more far- reaching effects, so I think the minor Control.hs modification is good for now. I'll clean it up, add a comment or two, and then make a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 18:49:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 18:49:50 -0000 Subject: [GHC] #10113: Re-export (<$>) and (<$) from Prelude In-Reply-To: <042.94e62203b187cd4423f8632566f19490@haskell.org> References: <042.94e62203b187cd4423f8632566f19490@haskell.org> Message-ID: <057.d76278d6df40931df01f754bdba5725f@haskell.org> #10113: Re-export (<$>) and (<$) from Prelude -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: closed Priority: highest | Milestone: 7.10.1 Component: libraries/base | Version: 7.10.1-rc2 Resolution: fixed | Keywords: AMP Operating System: Unknown/Multiple | report-impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4834 | Test Case: | Blocking: | Differential Revisions: Phab:D680 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged, thanks Herbert. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 18:52:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 18:52:40 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.057da940c183e562254c66bb2139d977@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: merge Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Cross Operating System: Linux | compiling Type of failure: Building GHC | Architecture: x86 failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"2aef3205115b88be8c068739c136eadc8c07e886/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2aef3205115b88be8c068739c136eadc8c07e886" hsc2hs: update submodule This includes the fix for #9524. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 18:54:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 18:54:27 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling In-Reply-To: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> References: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> Message-ID: <064.4302a8ad824de0df23829668a0baa23c@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.4 Resolution: fixed | Keywords: Cross Operating System: Linux | compiling Type of failure: Building GHC | Architecture: x86 failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Merged, thanks Eric! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 18:54:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 18:54:51 -0000 Subject: [GHC] #10058: Panic: Loading temp shared object failed In-Reply-To: <047.df96ee90c5cc42a1abdc47b2157e041f@haskell.org> References: <047.df96ee90c5cc42a1abdc47b2157e041f@haskell.org> Message-ID: <062.bfc173be3f016538150eff3320eff327@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Runtime System | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10110 | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged, thanks Peter! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 18:55:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 18:55:20 -0000 Subject: [GHC] #10128: Data.List.transpose needs more docs In-Reply-To: <046.278998fc9f3fb8250696da3cd44346be@haskell.org> References: <046.278998fc9f3fb8250696da3cd44346be@haskell.org> Message-ID: <061.935cd81bba4f7c64bd835c003bd3a78e@haskell.org> #10128: Data.List.transpose needs more docs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 18:58:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 18:58:58 -0000 Subject: [GHC] #10100: Bogus "redundant constraint" warning with functional dependencies In-Reply-To: <048.9dcc7a939a45b31fb0e7cae24622ba1c@haskell.org> References: <048.9dcc7a939a45b31fb0e7cae24622ba1c@haskell.org> Message-ID: <063.5bb20a86e3e89abece6b96141de46c4a@haskell.org> #10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10100 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.1 => 7.12.1 Comment: Actually, after spending a second trying to merge this, I realized something very silly - `-fwarn-redundant-constraints` isn't in GHC 7.10 anyway! So, this can be closed I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 19:26:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 19:26:24 -0000 Subject: [GHC] Batch modify: #7651, #4471, #7478, #8095, #8736, #8832, #9198, #9968, #10067, #9821 Message-ID: <20150309192624.EFC6D3A2FF@ghc.haskell.org> Batch modification to #7651, #4471, #7478, #8095, #8736, #8832, #9198, #9968, #10067, #9821 by thoughtpolice: milestone to 7.12.1 Comment: Moving to the 7.12.1 milestone, as these tickets won't be fixed in time for the 7.10.1 release (unless you, the reader, help write a patch :) -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 19:33:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 19:33:40 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.866f9b0dfbc3679deaee22bd1d896141@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9722 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9722 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 19:43:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 19:43:37 -0000 Subject: [GHC] #2991: .tix file generation broken with -fhpc and --make flags with lhs modules In-Reply-To: <045.fbdf830be4083dc434ba708ecd719a55@haskell.org> References: <045.fbdf830be4083dc434ba708ecd719a55@haskell.org> Message-ID: <060.c146de0b0b18fcac09b91371ff27e14a@haskell.org> #2991: .tix file generation broken with -fhpc and --make flags with lhs modules -------------------------------------+------------------------------------- Reporter: ppavel | Owner: andy@? Type: bug | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.10.1 Resolution: | Keywords: hpc make Operating System: Unknown/Multiple | lhs Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: hpc/T2991 | Blocking: | Differential Revisions: Phab:D701 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"f9344f3646156a9efff2dcfb90e1d5d67fd4f5a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f9344f3646156a9efff2dcfb90e1d5d67fd4f5a1" Fix `ghc --make -fhpc` with imported lhs modules See Note [Don't normalise input filenames] in `compiler/main/DriverPipeline.hs`. Fixes #2991. Reviewers: austin Differential Revision: https://phabricator.haskell.org/D701 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 19:45:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 19:45:54 -0000 Subject: [GHC] #2991: .tix file generation broken with -fhpc and --make flags with lhs modules In-Reply-To: <045.fbdf830be4083dc434ba708ecd719a55@haskell.org> References: <045.fbdf830be4083dc434ba708ecd719a55@haskell.org> Message-ID: <060.040eb36a451413e51a63ecd318639025@haskell.org> #2991: .tix file generation broken with -fhpc and --make flags with lhs modules -------------------------------------+------------------------------------- Reporter: ppavel | Owner: andy@? Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.10.1 Resolution: fixed | Keywords: hpc make Operating System: Unknown/Multiple | lhs Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: hpc/T2991 | Blocking: | Differential Revisions: Phab:D701 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 20:24:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 20:24: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.e0b7730ffc058c393319f388a29bd5a1@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Did you try with the 7.10 release candidate (comment:4)? Maybe it is fixed already? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 20:31:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 20:31:08 -0000 Subject: [GHC] #10150: Suppress orphan instance warning per instance Message-ID: <045.dd025a940793eea395715281eec0b7db@haskell.org> #10150: Suppress orphan instance warning per instance -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the same way we have overlapping/incoherent instance pragmas which can be applied on a per instance basis, it would be good to have a `-fno-warn- orphan-instance` pragma which can be applied on a per-instance basis. Annoyingly, there is not an obvious syntax to use for this case, since SOP for a module with orphan instances is `{-# GHC_OPTIONS -fno-warn-orphans #-}` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 21:45:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 21:45:27 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.6096c93d080c17fce1184bc4f2b93389@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): Thank you for looking at this! Replying to [comment:1 nomeata]: > Here is a cue: Removing the `!` on `t` in `mkMachine` removes *all* trace output. So it seems that (possibly as a result of minimizing the code), `t` and hence `array_adjust` is not actually used. This (function strict in an argument, but argument is unused) might make GHC be a bit too liberal in what it does with the code. Yes, this is indeed a result of minimizing the code. I'll attach a version of the test program that does not rely solely on the bangs. In this version, if I remove the bangs in `mkMachine` (on both `m` and `t`), the amount of trace output grows exponentially (not quadratically) when compiled with `-O1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 22:10:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 22:10:08 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.979a8d53437553f9a068d98fbc096f10@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Thanks. It still relies on the bang in `gstep`. Also funny: Replacing `data Array' a = ALeaf a` by `newtype Array' a = ALeaf a` removes ''some'' repeated computation, but ''not all''. I?m curious about what causes this :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 22:15:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 22:15:46 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.342e3fe6d63f8e50e4ad952a2ec3ffda@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): It must be related to the `error` call in `adjustA`. Removing the branch, or replacing it by something terminating, even replacing it by `undefined` makes the bug disappear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 22:27:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 22:27:23 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.cda320bbc76d70d5d7c0c88127bc8637@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I tried to further minimize the code. Note that `undefined i` is required; if does not exhibit the bug with just `undefined`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 22:28:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 22:28:14 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.e55e7751ac2bfbda841d23f9d32594ed@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714 -------------------------------------+------------------------------------- Comment (by Andreas Voellmy ): In [changeset:"74625d6847e970e8bdc6991c327515b3e10b231b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="74625d6847e970e8bdc6991c327515b3e10b231b" RTS/IOManager: fix trac issue #9722. Summary: Whenever the RTS has been inactive for idleGCDelayTime, the idle timer fires and calls wakeUpRts(), which in turn calls ioManagerWakeup(), which in turn writes a byte (or a few) to a file descriptor (stored in the io_manager_wakeup_fd variable) registered by the TimerManager and on which the TimerManager will wait. (Note that the write will only occur if the file descriptor is non-negative.) When the RTS shuts down, it shuts down the TimerManager, and in this process the file descriptor stored in io_manager_wakeup_fd is closed. In the error case, the idle timer fires after the close of the file occurs, and then the write() call in ioManagerWakeup() fails and the aforementioned error message gets printed. This patch solves the problem by (1) having the TimerManager (via Control) write -1 to io_manager_wakeup_fd just before closing the file descriptor written in io_manager_wakeup_fd, and (2) having ioManagerWakeup() ignore an error returned by write() in the case that the write returned -1 and the io_manager_wakeup_fd is -1. Reviewers: austin, simonmar, hvr, thomie Reviewed By: thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D722 GHC Trac Issues: #9722 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 22:29:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 22:29:58 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.6710aa57c9f6854ceb2fa2e07d7cb791@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714, | Phab:D722 -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * status: patch => merge * differential: Phab:D714 => Phab:D714, Phab:D722 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 9 22:37:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Mar 2015 22:37:14 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.7a9f9b84dc1ed01dd6be9a21ff19768d@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK, good. With your reduced test case I can reproduce the bug. I've produced a much smaller version, in two variants {{{ ---------- RSR.hs-boot ------------ module RSR where data RSR instance Eq RSR ---------- SR.hs ------------ module SR where import {-# SOURCE #-} RSR data SR = MkSR RSR deriving( Eq ) ---------- SR.hs ------------ module RSR where import SR data RSR = MkRSR SR deriving( Eq ) }}} Now compile like this {{{ ghc -c -O RSR.hs-boot ghc -c -O SR.hs ghc -c -O RSR.hs }}} Indeed, compiling `RSR` causes infinite inlining. Here's a version that doesn't use instances and so is a bit clearer {{{ ---------- RSR.hs-boot ------------ module RSR where data RSR eqRSR :: RSR -> RSR -> Bool ---------- SR.hs ------------ module SR where import {-# SOURCE #-} RSR data SR = MkSR RSR eqSR (MkSR r1) (MkSR r2) = eqRSR r1 r2 ---------- SR.hs ------------ module RSR where import SR data RSR = MkRSR SR -- deriving( Eq ) eqRSR (MkRSR s1) (MkRSR s2) = (eqSR s1 s2) foo x y = not (eqRSR x y) }}} This fails in the same way. The problem is this. When compiling `RSR` we get this code {{{ RSR.eqRSR :: RSR.RSR -> RSR.RSR -> GHC.Types.Bool RSR.eqRSR = \ (ds_dkA [Occ=Once!] :: RSR.RSR) (ds_dkB [Occ=Once!] :: RSR.RSR) -> case ds_dkA of _ { RSR.MkRSR s1_aeO [Occ=Once] -> case ds_dkB of _ { RSR.MkRSR s2_aeP [Occ=Once] -> SR.eqSR s1_aeO s2_aeP } } RSR.foo :: RSR.RSR -> RSR.RSR -> GHC.Types.Bool RSR.foo = \ (x_aeQ [Occ=Once] :: RSR.RSR) (y_aeR [Occ=Once] :: RSR.RSR) -> GHC.Classes.not (RSR.eqRSR x_aeQ y_aeR) }}} Notice that neither are (apprently) recursive, and neither is a loop breaker. Now, when optimising `foo`: * Inline `eqRSR` * Inline `eqSR` but the result of inlining `eqSR` from `SR` is another call to `eqRSR`, so everything repeats. It's pretty simple, so I'm quite surprised that this hasn't bitten us before now! Next: figure out a solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 00:13:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 00:13:08 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.13de479674f9845afc1e8e83fcc1d5ea@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: #9268 | Differential Revisions: ----------------------------------------+--------------------------------- Comment (by erikd): As @rwbarton pointed out in D715, ghc does not call ld directly, but cabal might (via the ld fields in the ghc settings file). Instead of setting `ld command` to `/usr/bin/ld` it should probably be set to `/usr/bin/ld.gold` and the cross compile issue has to be looked at as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 00:45:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 00:45:47 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.df039f0e90502e85e78b9efa9f971262@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D715 Related Tickets: #9268 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D715 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 02:18:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 02:18:20 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.f0624e55fe30b1afd5cef54cf95024aa@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect result | Blocking: at runtime | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by amurrayc): Aha! I finally got the device compiler to build using HEAD with LLVM 3.6 from homebrew. I had to modify the ghc-ios-scripts to pick up clang from the homebrew 3.6 install but it seems to work. The test case prints out 29.0 as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 03:09:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 03:09:05 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.b946eedfca879c84955e75ca088c4924@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D715 Related Tickets: #9268 | -------------------------------------+------------------------------------- Comment (by erikd): The `ld.gold` linker seems to be the right thing to use when targeting Linux and android, but what about iOS? Should that just be left to use plain `ld`? Maybe @rwbarton knows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 03:56:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 03:56:36 -0000 Subject: [GHC] #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide In-Reply-To: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> References: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> Message-ID: <060.5d1d492127cddd52c6ab7e59f2fe3516@haskell.org> #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by David Terei ): In [changeset:"c1db477151c2c1a330081fd0b4aab29bd85b636f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1db477151c2c1a330081fd0b4aab29bd85b636f" Changes to Safe Haskell documentation from feedback (#10140). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 04:05:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 04:05:40 -0000 Subject: [GHC] #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide In-Reply-To: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> References: <045.77ba982550f7d05bce83f27fed3b7fd3@haskell.org> Message-ID: <060.78aa690cb1f701c9a4362892ef7933ec@haskell.org> #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dterei): * status: new => closed * resolution: => fixed Comment: Made some changes I think should address the feedback. Thanks once again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 04:43:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 04:43:10 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.eec8283940c68897c542983bf23bf5ea@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by ekmett): That was me speaking as me, not in any official capacity. =) I had honestly thought FlexibleContexts _was_ the extension for this sort of thing until now. Putting on my CLC hat for a bit, the main reason I can see why it'd be nice to have FlexibleContexts "just work" is it means we don't have to make the hackage trustees go back and retrofit all sorts of old versions of packages with base upper bounds wherever they find themselves encountering this issue. But mostly that rises to the left of "nice to have" not really "have to have". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 04:58:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 04:58:17 -0000 Subject: [GHC] #10114: Kind mismatches with AnyK in rank-2 types In-Reply-To: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> References: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> Message-ID: <057.b1c3b39231eacce54c93d468235e02cb@haskell.org> #10114: Kind mismatches with AnyK in rank-2 types -------------------------------------+------------------------------------- Reporter: cam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * cc: sweirich@? (added) Comment: Replying to [comment:5 simonpj]: > So I think I retract my claim in comment:1. Perhaps we do want to generalise "inside". I agree with your (now retracted) claim. If `T = forall k1 k2 (f :: k1 -> k2) (a :: k1). f a`, then I think `T`'s type would have to be `k2`, which is nonsense. As I understand it, the kind of a forall-type is the kind of the body of the forall-type. > > Can anyone say why it is "generally more common to restrict the body of a forall to have kind `*`"? I can't articulate a clear argument. This claim of mine is direct from Stephanie. Stephanie, do you know why this is? > > In GHC's case, a good reason not to do this was types like `forall a. a -> (# a, a #)`, but levity polymorpism will help here. I don't think that's quite what you want to say, because the kind of the body of that forall is `*`! Maybe `forall a. (# a, a #)`? I don't see how levity polymorphism fixes this problem. Even with levity polymorphism, the kind of the body of that last forall is still `#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 07:11:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 07:11:15 -0000 Subject: [GHC] #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.dfc6e91444425713faa0aef3fed19c3c@haskell.org> #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"19440ae2bb256f75934949ae57934caee3831a80/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="19440ae2bb256f75934949ae57934caee3831a80" ghc-prim : Hide 64 bit primops when the word size is 32 bits (fixes #9886). Summary: These primops were failing to compile on PowerPC (32 bit). There is also currently no way to call into these primops from Haskell code. Currently, the *only* way to call any of these C hs_atomic_* functions is via the fetch*IntArray primops which are only defined for Int values and Int is always the native word size. When these functions can be called (and tested) from Haskell code, then it will be worth while implementing them. Test Plan: Compile and run on x86, x86_64, powerpc and arm: testsuite/tests/concurrent/should_run/AtomicPrimops.hs Reviewers: tibbe, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D702 GHC Trac Issues: #9886 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 09:41:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 09:41:12 -0000 Subject: [GHC] #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.c254115a01898666af23b65a8efbd534@haskell.org> #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Changes (by erikd): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 09:55:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 09:55:49 -0000 Subject: [GHC] #7854: Constrained method type accepted in Haskell 98 mode In-Reply-To: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> References: <045.1e7de6fac146df736db3494e806c1e91@haskell.org> Message-ID: <060.6bffddd4f3bdfe7a61b731473b12f7ff@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by simonpj): Two thoughts * I'm relaxed about what we choose here. It really matters little; and it's been a long-standing bug in GHC. * You do have a point: that `FlexibleContexts` sounds as if it has to do with type-signature contexts (and it does); and so does `ConstrainedClassMethods`. So perhaps it would be more intuitive to make `FlexibleContexts` imply `ConstrainedClassMethods` than `MultiParamTypeClasses`? But I bet there are packages that use `MultiParamTypeClasses` but not `FlexibleContexts`. So * Perhaps we should try making `FlexibleContexts` imply `ConstrainedClassMethods`, but ''not'' `MultiParamTypeClasses`, just to see what happens. * If it's painful, then maybe the path of least resistance is to make both imply `ConstrainedClassMethods`. Any views from others? Would someone like to try the experiment? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 10:24:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 10:24:45 -0000 Subject: [GHC] #10150: Suppress orphan instance warning per instance In-Reply-To: <045.dd025a940793eea395715281eec0b7db@haskell.org> References: <045.dd025a940793eea395715281eec0b7db@haskell.org> Message-ID: <060.1ae1182cbfb8745a7a8bb4930a0d5faf@haskell.org> #10150: Suppress orphan instance warning per instance -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I agree with the idea here, if someone wants to pursue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 10:25:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 10:25:12 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.572dce7d541bcdd8148e3d2b20695976@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D715 Related Tickets: #9268 | -------------------------------------+------------------------------------- Comment (by erikd): When target iOS, Apple has its own linker. `ld.gold` should only be used when targeting arm/linux and arm/android. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 10:28:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 10:28:22 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.cbf222becb5fa7224ccf56d52c0d7de4@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): Looking at Core and STG outputs for `repeated2.hs`, it looks like incorrect demand information is causing the problem. ghc 7.10.20150123 produces the following core for `gstep` when invoked with `-O1 -fno-state-hack`: {{{ Rec { Main.$wgstep [InlPrag=[0], Occ=LoopBreaker] :: GHC.Types.Int -> GHC.Prim.Int# -> (# GHC.Types.Int -> Main.Machine, GHC.Types.Int #) [GblId, Arity=2, Str=DmdType , Unf=OtherCon []] Main.$wgstep = \ (ww :: GHC.Types.Int) (ww1 [Occ=Once] :: GHC.Prim.Int#) -> case GHC.Prim.<# ww1 0 of sat { __DEFAULT -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool sat of _ [Occ=Dead] { GHC.Types.False -> let { ipv [Occ=OnceL, Dmd=] :: GHC.Types.Int [LclId, Str=DmdType] ipv = let { sat [Occ=Once, Dmd=] :: GHC.Base.String [LclId, Str=DmdType] sat = let { sat [Occ=Once] :: [GHC.Types.Char] [LclId, Str=DmdType] sat = case ww of _ [Occ=Dead] { GHC.Types.I# ww3 [Occ=Once] -> case GHC.Show.$wshowSignedInt 0 ww3 (GHC.Types.[] @ GHC.Types.Char) of _ [Occ=Dead] { (# ww5 [Occ=Once], ww6 [Occ=Once] #) -> GHC.Types.: @ GHC.Types.Char ww5 ww6 } } } in GHC.CString.unpackAppendCString# "adj "# sat } in Debug.Trace.trace @ GHC.Types.Int sat ww } in let { sat [Occ=Once] :: GHC.Types.Int -> Main.Machine [LclId, Str=DmdType] sat = \ (w [Occ=Once!] :: GHC.Types.Int) -> case w of _ [Occ=Dead] { GHC.Types.I# ww3 [Occ=Once] -> case Main.$wgstep ipv ww3 of _ [Occ=Dead] { (# ww5 [Occ=Once], ww6 [Occ=Once] #) -> Main.Machine ww5 ww6 } } } in (# sat, ww #); GHC.Types.True -> case GHC.Err.undefined of _ [Occ=Dead] { } } } end Rec } }}} Note the `ipv [Occ=OnceL, Dmd=]` part. If I understand it correctly, `Dmd` claims that `ipv` will not be used at all. However, this is wrong and `ipv` will be used in the recursive call to `Main.$wgstep`. This demand info then causes a single-entry closure (`\s`) to be generated for `ipv` in the STG. If I replace the `undefined i` with just `undefined` in the source file, the corresponding definition has no demand information, and its closure is marked as updatable (`\u`) rather than single-entry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 11:09:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 11:09:49 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.df188518e59342b5f7fd23bf62bda507@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Very helpful diagnosis. That does look like a real bug. Thanks. Keep studying it because I'm tied up right now; but you've got close to the problem! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 14:25:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 14:25:59 -0000 Subject: [GHC] #10114: Kind mismatches with AnyK in rank-2 types In-Reply-To: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> References: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> Message-ID: <057.bc653cc131841a7062b4ae4b3aa519c6@haskell.org> #10114: Kind mismatches with AnyK in rank-2 types -------------------------------------+------------------------------------- Reporter: cam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It's amazing how easily I can be confused by this stuff! To the question of why restricting foralls to have result of kind `*`, maybe I can attempt to answer my own question, thus: in what context could you could use such a type? Obviously not in a type signature, since that must have kind `*`. Where else? Would it make sense to say `T (forall a. Either a)`? But if `T` expected an arg of kind `* -> *`, does it make sense to instantiate it with `(forall a. Either a)`? Does the type `(forall a. Either a) Int` make sense? Maybe not. Re unboxed tuples, maybe you are right. Perhaps it only matters in very special cases like `forall a. (# a, a #)` which may not be very important. In short, maybe we should explore * `forall` always has kind `*` * Kind-generalise the RHS of type synonyms, so we get the kind in comment:4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 14:44:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 14:44:11 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.93e043911528451507a86ce381c0c7dd@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): @goldfire Substituting `MonoLocalBinds` for `TypeFamilies` in my most recent example also compiles fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 15:14:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 15:14:33 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.30cdb633ce9d99a958eb60d0398fccdf@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): IIRC Travis still runs Ubuntu 12.04LTS -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 15:23:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 15:23:06 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.2cba672fb9cd9de916454211e7b65090@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Comment (by simonpj): Richard has now completed a draft, at Phab:D653, but it's pretty big, and is unlikely to carry over to the 7.10 branch without a lot of fuss (and hence potential errors). Austin will try and report. But otherwise we may just have to do without it. We are very far down the road to 7.10 and I don't want to destablise it. Is that too terrible? (Edward esp.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 18:13:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 18:13:48 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.52e17cc828596cd57adb4484c7339ef5@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D637 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Merged, thanks Alexander! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 18:31:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 18:31:20 -0000 Subject: [GHC] #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) Message-ID: <049.f0ae68dfd7e58122643bba7078f24559@haskell.org> #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: jaseemabid | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I was experimenting in ghci and this happened. {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/mj/k7lrnmkn13v753mbj7q6fmy00000gn/T/ghc32761_0/ghc32761_77.dylib, 9): Symbol not found: __hpc_tickboxes_lisperzm0zi1zi0zi0_LisperziCore_hpc Referenced from: /var/folders/mj/k7lrnmkn13v753mbj7q6fmy00000gn/T/ghc32761_0/ghc32761_77.dylib Expected in: flat namespace in /var/folders/mj/k7lrnmkn13v753mbj7q6fmy00000gn/T/ghc32761_0/ghc32761_77.dylib }}} Complete source code of the project that caused this: https://github.com/jaseemabid/lisper ghc version: 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 18:49:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 18:49:06 -0000 Subject: [GHC] #10146: Clang CPP adds extra newline character In-Reply-To: <049.7d16de83828bec74f9ab166d6dbd4393@haskell.org> References: <049.7d16de83828bec74f9ab166d6dbd4393@haskell.org> Message-ID: <064.f7518da5ee91b1221a8d0c10ddad777a@haskell.org> #10146: Clang CPP adds extra newline character -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): I think you're right that it's not a GHC issue and there's nothing that would be sensible to change in GHC. It's possible to reverse some simple CPP changes but you're right that in general it is a difficult problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 20:22:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 20:22:37 -0000 Subject: [GHC] #10081: SIGTERM ignored when process has been detached from terminal In-Reply-To: <044.1f8bc4458608289c276bfd2ddfa7272f@haskell.org> References: <044.1f8bc4458608289c276bfd2ddfa7272f@haskell.org> Message-ID: <059.ebc4ea2214494b8e598a615cb40c5239@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nakal): I want to confirm that your solution works. Thank you. I tried before with `bracket`. I guess, I messed up something. Also, I find the behavior a bit strange (default ignoring of exceptions in trap handler), but I guess it is OK in this way. You can close this report. It has been my misunderstanding how exceptions work in signal handlers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 21:53:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 21:53:28 -0000 Subject: [GHC] #10152: Testsuite diffs can be misleading when normalisers are in use Message-ID: <045.9e8cc1c7996562f5a21caab577ceef49@haskell.org> #10152: Testsuite diffs can be misleading when normalisers are in use -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When output fails to match, GHC will output the diff based on the original outputs. However, this is misleading: some "differences" will actually have been normalised by the whitespace and more substantive normalisers we apply. So you really have to compare the normalised output to see what the /real/ difference is. Unfortunately, the real normalised output is missing newlines, so it's not really suitable for diffing. So it's not really clear what an improved algorithm would be. This seems to not actually be a problem in practice, since SOP for messages which need heavy normalizing is that when the new message looks good, it's just 'make accept'ed. Can be a little confusing when you're developing normalisers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 10 22:20:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Mar 2015 22:20:08 -0000 Subject: [GHC] #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) In-Reply-To: <049.f0ae68dfd7e58122643bba7078f24559@haskell.org> References: <049.f0ae68dfd7e58122643bba7078f24559@haskell.org> Message-ID: <064.17c08d070ea1b205f65e5cc4d01394e7@haskell.org> #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) -------------------------------+------------------------------------------- Reporter: jaseemabid | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Changes (by trommler): * cc: hvr (added) * failure: None/Unknown => GHCi crash * status: new => infoneeded * component: Compiler => GHCi Comment: This looks like #10058 which is fixed in HEAD. Can you try your code with HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 00:41:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 00:41:47 -0000 Subject: [GHC] #10153: GHC mode for converting files to explicit layout Message-ID: <045.a5b570a1f5407066e4458fa718968fd2@haskell.org> #10153: GHC mode for converting files to explicit layout -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- One area where GHC is a little less friendly to newcomers is its Byzantine whitespace layout rules. Once you've gotten used to using GHC you can usually get what you want by abiding certain style, but before then it might be useful to see how GHC is inserting semicolons to your document. I don't think this would be too hard to do. The idea is to get the token stream and look for virtual curlies with no location. Once you have a list of them, you can go over the original buffer again and insert a brace or semicolon whenever you see a token like this. Might be a good beginner task. This function would also be useful for debugging layout, since knowing if semicolons are being inserted is useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 10:13:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 10:13:02 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.622d337569feeaeb514c853a332521f4@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: dominiquedevriese | Status: new Type: feature request | Milestone: Priority: low | Version: 7.8.3 Component: Compiler (Type | Keywords: holes checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 11:13:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 11:13:39 -0000 Subject: [GHC] #3283: Selective disabling of unused bind warnings In-Reply-To: <042.99c53619193c24de1883dd2c0ccb355d@haskell.org> References: <042.99c53619193c24de1883dd2c0ccb355d@haskell.org> Message-ID: <057.5617bb91157520c4ae3da87bccb46796@haskell.org> #3283: Selective disabling of unused bind warnings -------------------------------------+------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #17 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:3 nomeata]: > It seems to be related to #17. I just came across this one and thought the same thing. Now that #17 is closed can we consider this a duplicate? I know this ticket proposes a separate pragma to mark definitions as used but with new warning flags added by #17 the pragma does not seem like a good idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 13:09:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 13:09:14 -0000 Subject: [GHC] #10114: Kind mismatches with AnyK in rank-2 types In-Reply-To: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> References: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> Message-ID: <057.66b017f7d6168fc66abba66270838ec5@haskell.org> #10114: Kind mismatches with AnyK in rank-2 types -------------------------------------+------------------------------------- Reporter: cam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): When someone (possibly me, but not before April) explores this, a good way forward is to just change !CoreLint around this issue and then to recompile GHC, the libraries, and the test suite, all with `-dcore-lint` enabled. I'm 99% sure that the usage of `forall` with a non-`*` body will show up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 14:11:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 14:11:01 -0000 Subject: [GHC] #10099: cabal install broken with ghc 7.10.1-rc2 In-Reply-To: <047.602c37795a358463eb57e7ffa8e992ef@haskell.org> References: <047.602c37795a358463eb57e7ffa8e992ef@haskell.org> Message-ID: <062.9ce4550aed29a9250b8a778f520d158a@haskell.org> #10099: cabal install broken with ghc 7.10.1-rc2 -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Package system | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: the Cabal submodule was updated to 1.22.1.0 (via 00c971ef9dbd16e2201df3ac63f2a68c4b9c0ff0) and subsequently again to 1.22.1.1 (via fdb72839fbefc439ac729e01fcb98fa6bd6511cc) in GHC HEAD as well as ghc-7.10. Therefore I assume this issue is resolved... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 14:24:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 14:24:43 -0000 Subject: [GHC] #5108: Allow unicode sub/superscript symbols in both identifiers and operators In-Reply-To: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> References: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> Message-ID: <072.e613aca6c704c7dc63517f27332e2c80@haskell.org> #5108: Allow unicode sub/superscript symbols in both identifiers and operators -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Status: infoneeded Type: feature request | Milestone: 7.12.1 Priority: normal | Version: 7.1 Component: Compiler | Keywords: lexer (Parser) | unicode Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): {{{ ?> let ?x?y = 1 }}} GHC 7.10 follows Unicode standard 7.0, in which `'?'` (`'\x2b9'`) is in the `ModifierLetter` (Lm) general category, so that will no longer compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 14:32:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 14:32:22 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5OTQ3OiBVbmljb2RlIMKrb3RoZXIgbnVtYmVy?= =?utf-8?q?=C2=BB_characters_not_consistently_accepted_in_identif?= =?utf-8?q?iers?= In-Reply-To: <045.361e5fa432ad2a6e4cd46ab590186633@haskell.org> References: <045.361e5fa432ad2a6e4cd46ab590186633@haskell.org> Message-ID: <060.0091ba0bcfd3c20847e2ff9a6d800a49@haskell.org> #9947: Unicode ?other number? characters not consistently accepted in identifiers -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4373 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * related: => #4373 Comment: I can not reproduce your problem. U+2460 and U+00B2 are treated in the same way: allowed in variable identifiers, not allowed in operator identifiers. Just like numbers. This compiles: {{{#!hs -- Superscript two (U+00B2) -- Block: Latin-1 Supplement -- General Category: OtherNumber (No) -- Haskell: number xB2 = '?' xB2_? = 4 -- Error (numbers not allowed in operators): -- data a +? b = XB2 a b -- Circle digit 1 (U+2460) -- Block: Enclosed Alphanumerics -- General Category: OtherNumber (No) -- Haskell: number x2460 = '?' x2460_? = 1 -- Error (numbers not allowed in operators): --data a +? b = X2460 a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 14:35:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 14:35:31 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5OTQ3OiBVbmljb2RlIMKrb3RoZXIgbnVtYmVy?= =?utf-8?q?=C2=BB_characters_not_consistently_accepted_in_identif?= =?utf-8?q?iers?= In-Reply-To: <045.361e5fa432ad2a6e4cd46ab590186633@haskell.org> References: <045.361e5fa432ad2a6e4cd46ab590186633@haskell.org> Message-ID: <060.135ec02da9e7bfbba9b1b15c87f12119@haskell.org> #9947: Unicode ?other number? characters not consistently accepted in identifiers -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4373 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): That is with GHC 7.8.4. Please supply a small code snippet that you expect to work, but doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 16:46:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 16:46:21 -0000 Subject: [GHC] #9607: Programs that require AllowAmbiguousTypes in 7.8 In-Reply-To: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> References: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> Message-ID: <063.1de8dd831f2635f052489ea251a5cf00@haskell.org> #9607: Programs that require AllowAmbiguousTypes in 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by trevorcook): Thanks for the insight. So, this is bad design, and an instance where ambiguity was mistakenly sought in the wild. I was vaguely aware of the mistake, but thought using the ambiguity flag made it all fine. In summary, I was attempting to make a configurable, general purpose function, but giving no way for the user to control the configuration, i.e. which instances of the class constraints containing 'c' to use. Hence the ambiguity. A solution which doesn't require AllowAmbiguousTypes is to let the user specify the configuration by handing forwardingAction some data. Below, I have a similar function which effectively passes the 'ServerAction' method call wrapped in a data ServCfg. {{{#!hs newtype ServCfg st cmd resp c = ServCfg { runService :: st -> cmd ->(resp,c->ComResp cmd)} maybeFwdAction :: forall st cmd trig b c . (ClientAction trig VisCom b) => ServCfg st cmd (Maybe (trig, b->c)) c -> st -> cmd -> (Maybe ([VisCom],[VisResp] -> c), c -> ComResp cmd) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 18:42:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 18:42:13 -0000 Subject: [GHC] #10153: GHC mode for converting files to explicit layout In-Reply-To: <045.a5b570a1f5407066e4458fa718968fd2@haskell.org> References: <045.a5b570a1f5407066e4458fa718968fd2@haskell.org> Message-ID: <060.93dc1f8d62bdfa469bc4e8b455c30888@haskell.org> #10153: GHC mode for converting files to explicit layout -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Parser) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer Comment: Adding "newcomer" keyword as suggested in original post. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 18:47:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 18:47:03 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.640e5db3c19fd634d064000244d12724@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Comment (by goldfire): Just to clarify, the original report with this ticket ''is'' actually already fixed in the 7.10 branch (see comment:12). It's just that the fix in 7.10 is very incomplete, as Simon points out in comment:9. That said, the fix in 7.10 doesn't introduce ''new'' bad behavior. So, if we're happy to live with #7788, #8550, #9554, and #10139, then we can avoid merging this to 7.10. Personally, this is a hard call. If we don't merge, then various (ill- typed) programs will cause GHC to hang, sometimes mysteriously. In particular, #10139 has a program without `UndecidableInstances` but that hangs 7.10RC2. The patch at Phab:D653 allows the program to compile. But I see how this change could rock the boat! I certainly welcome other opinions about how to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 19:01:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 19:01:47 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.fce31cfa3593479fee757716bfe52cce@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hedayaty): Thanks @simonpj for a minimal reproduction of the issue. The bug exists in 6.10 RC2 as well -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 19:49:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 19:49:04 -0000 Subject: [GHC] #10081: SIGTERM ignored when process has been detached from terminal In-Reply-To: <044.1f8bc4458608289c276bfd2ddfa7272f@haskell.org> References: <044.1f8bc4458608289c276bfd2ddfa7272f@haskell.org> Message-ID: <059.ac1c8d375993afa67b81b327eeb1ddca@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: > I tried before with `bracket`. Ah, but `bracket` reraises the exception after running the cleanup action, so that's why the `throwTo` was still not reached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 20:10:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 20:10:24 -0000 Subject: [GHC] #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.186c5e614ef25d453b7d437dac7b9347@haskell.org> #9886: PowerPC : Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (CodeGen) | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged (via bd785d101766a1207b8d27a45b6ae0bf83cd678a), thanks Erik. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 20:12:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 20:12:03 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.81564d7f1aa9a369dac36972ec71d9cc@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: Phab:D714, | Phab:D722 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged (via fb2ab1e3e04fde78d8970815f83b90d54359ae82), thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 20:30:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 20:30:54 -0000 Subject: [GHC] #10101: ghci :e throws exception after type error In-Reply-To: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> References: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> Message-ID: <062.94bb0ede97f538f966fd43a3ba4eb2fc@haskell.org> #10101: ghci :e throws exception after type error -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by glguy): * version: 7.11 => 7.10.1-rc2 Comment: This is a regression in the 7.10 series relative to 7.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 22:42:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 22:42:11 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path In-Reply-To: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> References: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> Message-ID: <060.cd5a5eef701cefdbbb40a73d068f34ed@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D704 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"41e8400a57620978681663e9c804fee405da26d5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="41e8400a57620978681663e9c804fee405da26d5" Update submodule hpc (includes fix for #9619) Reviewers: austin Differential Revision: https://phabricator.haskell.org/D704 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 11 22:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Mar 2015 22:47:57 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path In-Reply-To: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> References: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> Message-ID: <060.a01caed6beed32a4368b8086d8b7caec@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | libraries/hpc/tests/simple/tixs/T9619 Related Tickets: | Blocking: | Differential Revisions: Phab:D704 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => libraries/hpc/tests/simple/tixs/T9619 * resolution: => fixed Comment: This will be fixed in 7.12. The relevant commit in the hpc library: https://github.com/ghc/packages- hpc/commit/f601495ac5f93f24cbcaa95f45b1bc26ad644ac9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 01:33:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 01:33: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.f37f94875a3fa9c1967adab539250236@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cactus): Just thinking out loud here, but does the PatternMatchCheck story have something to offer us here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 01:42:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 01:42:57 -0000 Subject: [GHC] #5567: LLVM: Improve alias analysis / performance In-Reply-To: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> References: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> Message-ID: <060.66da28164405e3892187f6723944a0a3@haskell.org> #5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 03:38:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 03:38:29 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.1c791168d084c813c2b535c4a1a3c277@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D715 Related Tickets: #9268 | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"71fcc4c096ec0b575522e4c2d0104ef7a71a13c5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="71fcc4c096ec0b575522e4c2d0104ef7a71a13c5" Use the gold linker for linux/ARM and android/ARM targets. Fixes #8976 and #9873 by making use of the Binutils ld.gold linker explicit whenever the target is linux/ARM or android/ARM. This does not affect iOS where Apple provides its own linker. In order to achieve this, we need to add `-fuse-ld=gold` to the SettingsCCompilerLinkFlags setting and set SettingsLdCommand to `ld.gold` (or `${target}-ld.gold` when cross-compiling). In addition, simplifying the use of `$(CONF_GCC_LINKER_OPTS_STAGEn)`. This patch was tested by ensuring that the following worked as expected: * Native builds on linux/x86_64 (nothing changed). * Native builds on linux/arm (and uses the gold linker). * Linux to linux/arm cross compiles (and uses the cross gold linker). Contributions by Ben Gamari, Joachim Breitner and Reid Barton. Reviewers: nomeata, bgamari, austin, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D715 GHC Trac Issues: #8976 #9873 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 03:38:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 03:38:29 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.21570fd493b5d045a13a402ede1ca61f@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"71fcc4c096ec0b575522e4c2d0104ef7a71a13c5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="71fcc4c096ec0b575522e4c2d0104ef7a71a13c5" Use the gold linker for linux/ARM and android/ARM targets. Fixes #8976 and #9873 by making use of the Binutils ld.gold linker explicit whenever the target is linux/ARM or android/ARM. This does not affect iOS where Apple provides its own linker. In order to achieve this, we need to add `-fuse-ld=gold` to the SettingsCCompilerLinkFlags setting and set SettingsLdCommand to `ld.gold` (or `${target}-ld.gold` when cross-compiling). In addition, simplifying the use of `$(CONF_GCC_LINKER_OPTS_STAGEn)`. This patch was tested by ensuring that the following worked as expected: * Native builds on linux/x86_64 (nothing changed). * Native builds on linux/arm (and uses the gold linker). * Linux to linux/arm cross compiles (and uses the cross gold linker). Contributions by Ben Gamari, Joachim Breitner and Reid Barton. Reviewers: nomeata, bgamari, austin, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D715 GHC Trac Issues: #8976 #9873 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 04:03:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 04:03:39 -0000 Subject: [GHC] #9920: Segfault in arm binary with llvm 3.5 In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.884fcb9cd838097b6d557f9c207910f7@haskell.org> #9920: Segfault in arm binary with llvm 3.5 -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: LLVM 3.6 has been released with @bgamari's arm-lower-tail-calls patch and git HEAD now also expects llvm-3.6. I've been compiling GHC git HEAD on arm without this problem for weeks now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 04:10:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 04:10:43 -0000 Subject: [GHC] #9691: GHC-HEAD runtime is broken on arm In-Reply-To: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> References: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> Message-ID: <062.270d4ae4903dfd5ea48801cac8b409d9@haskell.org> #9691: GHC-HEAD runtime is broken on arm ----------------------------------+--------------------------------- Reporter: mkbrandt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------- Changes (by erikd): * status: new => closed * resolution: => wontfix Comment: I now have a Jenkins instance that builds and tests a linux/amd64 to linux/armhf and linux/arm64 cross-compiler from GHC git HEAD. These builds have be stable for a couple of weeks now. GHC git HEAD works because it uses the llvm 3.6 release. The GHC 7.8.* releases don't work with the released llvm-3.5 version, but the patch from #9920 applied to llvm-3.5 fixes that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 04:27:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 04:27:54 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive In-Reply-To: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> References: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> Message-ID: <062.4bbcdbbac6ed21c36447a8519c159c87@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 9308 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 04:28:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 04:28:54 -0000 Subject: [GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm In-Reply-To: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> References: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> Message-ID: <057.4f945c885f388ee1165e0b61031b6a3b@haskell.org> #9308: nofib fannkuch-redux runs perpetually with -fllvm -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: fannkuch- Operating System: Unknown/Multiple | redux Type of failure: Incorrect result | Architecture: x86_64 at runtime | (amd64) Blocked By: 9504 | Test Case: fannkuch- Related Tickets: #5567 | redux | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 04:33:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 04:33:59 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.0191e9c81a5670c903634b79fc24a28f@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D715 Related Tickets: #9268 | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 04:35:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 04:35:53 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.5f02eb630399e39a7ba24b7aa4aa36cd@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 07:55:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 07:55:58 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.3b004f9626cf13e016c1974dae7f401c@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D715 Related Tickets: #9268 | -------------------------------------+------------------------------------- Changes (by erikd): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 08:36:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 08:36:11 -0000 Subject: [GHC] #9541: ghc: panic, "RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order" In-Reply-To: <046.68efa89057831cb9c8ddc6a98623ef69@haskell.org> References: <046.68efa89057831cb9c8ddc6a98623ef69@haskell.org> Message-ID: <061.f980e8b55e9c4910ee3fee944e7f3765@haskell.org> #9541: ghc: panic, "RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order" -------------------------------------+------------------------------------- Reporter: aleator | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: No response from submitter. Please reopen if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 08:43:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 08:43:25 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path In-Reply-To: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> References: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> Message-ID: <060.007086dbef9d1c1c8f8e8d4614a498d6@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: merge Priority: lowest | Milestone: 7.10.1 Component: Code Coverage | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | libraries/hpc/tests/simple/tixs/T9619 Related Tickets: | Blocking: | Differential Revisions: Phab:D704 -------------------------------------+------------------------------------- Changes (by hvr): * status: closed => merge * milestone: 7.12.1 => 7.10.1 Comment: Since this landed into GHC HEAD a bit too soon, we're gonna have to cherry pick this into 7.10 to avoid git branching in the hpc submodule :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 08:50:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 08:50:30 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.b1a3341dab0ee1a686de3df02631e751@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm conscious that you (alone, as far as I can tell) are held up by this bug. I think I know how to fix it, but it's not entirely straightforward and we are very far down the road for 7.10. So I'd like to see if we can find a workaroud. Two suggestions. First idea. compile `RSR` (the one with an `hs-boot` file) with `-funfolding-use-threshold=0`. That will switch off inlining in that module only. Second idea (less brutal). In the first version (which is close to what you have), instead of {{{ data RSR = MkRSR SR deriving( Eq ) }}} say {{{ data RSR = MkRSR SR instance Eq RSR where (==) = eqRSR eqRSR :: RSR -> RSR -> Bool {-# NOINLINE eqRSR #-} eqRSR (RSR s1) (RSR s2) = s1==s2 }}} I think that'll work. It's tiresome because you can't use the auto- generated equality method, but your data types are small. You may need to do this for other instances. I hope that this will get you unglued. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 09:01:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 09:01:23 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path In-Reply-To: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> References: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> Message-ID: <060.64022537e0c9d601a4b5536be496e282@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Code Coverage | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | libraries/hpc/tests/simple/tixs/T9619 Related Tickets: | Blocking: | Differential Revisions: Phab:D704 -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed Comment: merged to GHC 7.10 via 029a296a770addbd096bbfd6de0936327ee620d4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 10:26:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 10:26:18 -0000 Subject: [GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) Message-ID: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: | Owner: masterdezign | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.3 Component: Compiler | Operating System: Linux Keywords: strange | Type of failure: Runtime crash closure type | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After compiling project with RTS options $ ghc --make -threaded Simul.hs -fforce-recomp -O2 and running it on Ubuntu 12.04 $ time ./Simul +RTS -N6 repeatedly received this message: Simul: internal error: evacuate: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Command terminated by signal 6 2131.46user 45.57system 6:13.95elapsed 582%CPU (0avgtext+0avgdata 185328maxresident)k 248inputs+0outputs (2major+11705minor)pagefaults 0swaps $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.3") ,("Booter version","7.4.1") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3") ,("Global Package DB","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3/package.conf.d") ] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 12:22:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 12:22:52 -0000 Subject: [GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) In-Reply-To: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> References: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> Message-ID: <066.853bc7dcf1d360d5eaa5de1d3d163518@haskell.org> #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: masterdezign | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: strange Operating System: Linux | closure type Type of failure: Runtime crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > After compiling project with RTS options > > $ ghc --make -threaded Simul.hs -fforce-recomp -O2 > > and running it on Ubuntu 12.04 > > $ time ./Simul +RTS -N6 > > repeatedly received this message: > > Simul: internal error: evacuate: strange closure type 983040 > (GHC version 7.8.3 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Command terminated by signal 6 > 2131.46user 45.57system 6:13.95elapsed 582%CPU (0avgtext+0avgdata > 185328maxresident)k > 248inputs+0outputs (2major+11705minor)pagefaults 0swaps > > $ ghc --info > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -fno-stack-protector") > ,("C compiler link flags","") > ,("Haskell CPP command","/usr/bin/gcc") > ,("Haskell CPP flags","-E -undef -traditional") > ,("ld command","/usr/bin/ld") > ,("ld flags","") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","YES") > ,("ld supports filelist","NO") > ,("ld is GNU ld","YES") > ,("ar command","/usr/bin/ar") > ,("ar flags","q") > ,("ar supports at file","YES") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSLinux") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","True") > ,("target has .ident directive","True") > ,("target has subsections via symbols","False") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.8.3") > ,("Booter version","7.4.1") > ,("Stage","2") > ,("Build platform","x86_64-unknown-linux") > ,("Host platform","x86_64-unknown-linux") > ,("Target platform","x86_64-unknown-linux") > ,("Have interpreter","YES") > ,("Object splitting supported","YES") > ,("Have native code generator","YES") > ,("Support SMP","YES") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn > thr_debug_dyn l_dyn thr_l_dyn") > ,("Support dynamic-too","YES") > ,("Support parallel --make","YES") > ,("Dynamic by default","NO") > ,("GHC Dynamic","YES") > ,("Leading underscore","NO") > ,("Debug on","False") > ,("LibDir","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3") > ,("Global Package > DB","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3/package.conf.d") > ] New description: After compiling project with RTS options $ ghc --make -threaded Simul.hs -fforce-recomp -O2 and running it on Ubuntu 12.04 $ time ./Simul +RTS -N6 repeatedly received this message: Simul: internal error: evacuate: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Command terminated by signal 6 2131.46user 45.57system 6:13.95elapsed 582%CPU (0avgtext+0avgdata 185328maxresident)k 248inputs+0outputs (2major+11705minor)pagefaults 0swaps $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.3") ,("Booter version","7.4.1") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3") ,("Global Package DB","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3/package.conf.d") ] Linux 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- Comment (by masterdezign): Linux 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 12:25:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 12:25:08 -0000 Subject: [GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) In-Reply-To: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> References: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> Message-ID: <066.216ac8e7e267075cb3ebbaf4380187c8@haskell.org> #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: masterdezign | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: strange Operating System: Linux | closure type Type of failure: Runtime crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by masterdezign: Old description: > After compiling project with RTS options > > $ ghc --make -threaded Simul.hs -fforce-recomp -O2 > > and running it on Ubuntu 12.04 > > $ time ./Simul +RTS -N6 > > repeatedly received this message: > > Simul: internal error: evacuate: strange closure type 983040 > (GHC version 7.8.3 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Command terminated by signal 6 > 2131.46user 45.57system 6:13.95elapsed 582%CPU (0avgtext+0avgdata > 185328maxresident)k > 248inputs+0outputs (2major+11705minor)pagefaults 0swaps > > $ ghc --info > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -fno-stack-protector") > ,("C compiler link flags","") > ,("Haskell CPP command","/usr/bin/gcc") > ,("Haskell CPP flags","-E -undef -traditional") > ,("ld command","/usr/bin/ld") > ,("ld flags","") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","YES") > ,("ld supports filelist","NO") > ,("ld is GNU ld","YES") > ,("ar command","/usr/bin/ar") > ,("ar flags","q") > ,("ar supports at file","YES") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSLinux") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","True") > ,("target has .ident directive","True") > ,("target has subsections via symbols","False") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.8.3") > ,("Booter version","7.4.1") > ,("Stage","2") > ,("Build platform","x86_64-unknown-linux") > ,("Host platform","x86_64-unknown-linux") > ,("Target platform","x86_64-unknown-linux") > ,("Have interpreter","YES") > ,("Object splitting supported","YES") > ,("Have native code generator","YES") > ,("Support SMP","YES") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn > thr_debug_dyn l_dyn thr_l_dyn") > ,("Support dynamic-too","YES") > ,("Support parallel --make","YES") > ,("Dynamic by default","NO") > ,("GHC Dynamic","YES") > ,("Leading underscore","NO") > ,("Debug on","False") > ,("LibDir","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3") > ,("Global Package > DB","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3/package.conf.d") > ] > > Linux 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 > x86_64 x86_64 GNU/Linux New description: After compiling project with RTS options $ ghc --make -threaded Simul.hs -fforce-recomp -O2 and running it on Ubuntu 12.04 $ time ./Simul +RTS -N6 repeatedly received this message: Simul: internal error: evacuate: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Command terminated by signal 6 2131.46user 45.57system 6:13.95elapsed 582%CPU (0avgtext+0avgdata 185328maxresident)k 248inputs+0outputs (2major+11705minor)pagefaults 0swaps $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.3") ,("Booter version","7.4.1") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3") ,("Global Package DB","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3/package.conf.d") ] Linux 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.1-2ubuntu1~12.04' --with- bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable- languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program- suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include- dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable- browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java- home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with- jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar- dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch- directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable- objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with- abi=m64 --with-multilib-list=m32,m64 --with-tune=generic --enable- checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 14:04:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 14:04:17 -0000 Subject: [GHC] #10105: ghc panic Simplifier ticks exhausted when trying UnfoldingDone x_alB In-Reply-To: <050.e25d389a8920cf1d1cafbe416375e037@haskell.org> References: <050.e25d389a8920cf1d1cafbe416375e037@haskell.org> Message-ID: <065.9c3f8c945c6fd780cd450edab7087397@haskell.org> #10105: ghc panic Simplifier ticks exhausted when trying UnfoldingDone x_alB -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dramforever): That's great! thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 18:57:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 18:57:15 -0000 Subject: [GHC] #8109: Type family patterns should support as-patterns. In-Reply-To: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> References: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> Message-ID: <065.343a865b9e405038cbe10b9ba974d9de@haskell.org> #8109: Type family patterns should support as-patterns. -------------------------------------+------------------------------------- Reporter: carlhowells | Owner: qnikst Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by qnikst): * owner: => qnikst -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 19:04:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 19:04:44 -0000 Subject: [GHC] #10149: The argument of mask does not always restore the masking state In-Reply-To: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> References: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> Message-ID: <071.9f7fba20b9c705da81e916337011acd1@haskell.org> #10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: libraries/base | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by qnikst): * cc: qnikst (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 20:00:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 20:00:09 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.2df6048906ddd25325c4877fafd94b27@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Comment (by goldfire): I'm stalled here. :( The work I've done in Phab:D653 works quite well on fixing the bugs listed there, but it fails utterly if it sees a recursive newtype. Consider test case typecheck/should_compile/tc159: {{{ newtype A = A [A] deriving (Eq) }}} GHC naturally tries to use GND here but then gives up when it can't flatten `A` w.r.t. representational equality. Before Phab:D653, this case was handled by the `rec_nts` trick -- a newtype could be unwrapped only once. The problem with this trick is that it makes type inference a little wonky: canonicalization wasn't idempotent! For example, canonicalizing `Coercible skolem A` would get you `Coercible skolem [A]`. Canonicalizing again would give you `Coercible skolem [[A]]` and so on. Putting the `rec_nts` logic in the flattener would make that algorithm non-idempotent. This seems bad. I've flailed around looking for a solution but am coming up dry. (The solution was around this idea: if flattening were stuck in a loop, just return the original unflattened type. This didn't work out in practice, though, because usually the first few steps of flattening were not loopy (i.e., following filled tyvars) and then the flattener would loop. But detecting the loop isn't exactly straightforward.) I see a few possible ways forward: - Accept that representational equality simply omits recursive newtypes. This means that `Note [Recursive newtypes]` in !TcDeriv would have to change, and some programs that compile today would fail to do so. - Continue to use the `rec_nts` trick, meaning that the flattener is not idempotent. Recursive newtypes will still be problematic, though, because the canonicalizer will see a newtype, try to flatten it away, partially succeed (unwrapping one level) and then loop, doing the same thing. Somehow, the canonicalizer would have to be taught not to do this. - Give up on moving unwrapping newtypes into the flattener and devise another way to fix comment:9. The flattener would retain the code I've put there to track type function depths, still fixing some of the tickets listed in comment:22. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 22:04:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 22:04:11 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.a5b02ae3b06ed541dee4b2efc6dd3ade@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hedayaty): OK. We can take the first one as default solution. Since the code is being generated, I can not modify the code. However, we might try diving into code generator! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 12 22:14:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Mar 2015 22:14:15 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.8366527384bc478faf3a090213e0d9b3@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317, #9159 | -------------------------------------+------------------------------------- Comment (by nomeata): Fist benchmarks results are in; binary sizes are reduced, runtime changes varies with a small tendency towards improvement: {{{ Size Allocs Runtime Elapsed TotalMem Min -1.8% -0.0% -4.5% -7.8% 0.0% Max -0.7% 0.0% +3.3% +3.4% +2.9% Geometric Mean -1.4% -0.0% -0.2% -0.6% +0.1% }}} The code still has some magic constants where an optimum could probably be found somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 00:16:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 00:16:25 -0000 Subject: [GHC] #9963: GHCi panic with --print-libdir flag In-Reply-To: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> References: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> Message-ID: <063.766139118d7036795be22298b9f9e889@haskell.org> #9963: GHCi panic with --print-libdir flag -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: thomie Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Driver | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie Comment: I know what's going on, just need to write a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 02:00:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 02:00:45 -0000 Subject: [GHC] #5539: GHC panic - Simplifier ticks exhausted In-Reply-To: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> References: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> Message-ID: <057.9b55d74872ac559c0b0099552853ce7c@haskell.org> #5539: GHC panic - Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): I can't reproduce the problem with the last example on 7.10.1 rc2. Can anybody reproduce it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 02:05:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 02:05:05 -0000 Subject: [GHC] #5539: GHC panic - Simplifier ticks exhausted In-Reply-To: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> References: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> Message-ID: <057.030f6d23d4bbec80c0412b174ce4a9ff@haskell.org> #5539: GHC panic - Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by George): * cc: george.colpitts@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 07:35:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 07:35:58 -0000 Subject: [GHC] #5539: GHC panic - Simplifier ticks exhausted In-Reply-To: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> References: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> Message-ID: <057.df2b4a6a34515995fb2da68ef9c05fa4@haskell.org> #5539: GHC panic - Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #8613, #9070, | Differential Revisions: #8319 | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8613, #9070, #8319 Comment: The examples from comment:45, comment:47 and comment:53 all compile on Linux with 7.8.4 and 7.10.1. The example from comment:34 still fails (run `cabal install vector-algorithms` first): {{{ module T5539 where import qualified Data.Vector.Algorithms.Intro as I import qualified Data.Vector.Generic as G partialSort :: (G.Vector v e, Ord e) => Int -> v e -> v e partialSort k = G.modify (\a -> I.partialSort a k) }}} Note that the `vector` package has received workarounds. See comments starting from comment:28. Related tickets from [wiki:Status/SLPJ-Tickets]: #8613, #9070, #8319: simplifier ticks exhausted (there are others). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 09:33:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 09:33:09 -0000 Subject: [GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) In-Reply-To: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> References: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> Message-ID: <066.b952d41e2a351c109434df6bcbef10cc@haskell.org> #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: masterdezign | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: strange Operating System: Linux | closure type Type of failure: Runtime crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => infoneeded Comment: Please provide the source code so that we can reproduce the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 13:37:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 13:37:17 -0000 Subject: [GHC] #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 Message-ID: <046.cfdb0dc1b2281b62f1e87667e0f4270a@haskell.org> #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 -------------------------------------+------------------------------------- Reporter: stengel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants where the ABI doesn't impose a mandatory red zone for the stack, like on Windows or Xen/HaLVM. The current implementation restores the stack pointer first, which effectively marks the area with the saved registers as reusable. Later, the CPU registers are restored from this "free" area. This ordering happens to work by accident on operating systems that strictly adhere to the System V ABI, because any interrupt/signal delivery is guaranteed to leave the first 128 bytes past the stack pointer untouched (red zone). On other systems this might result in corrupted CPU registers if an interruption happens just after restoring the stack pointer. The red zone is usually only used by small leaf functions to avoid updates to the stack pointer and exploiting it doesn't give us any advantage in this case. The attached patch reorders the register access, so that the stack pointer is restored last. It's also shorter by one instruction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 15:17:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 15:17:48 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.5d56ca9b05c83e394edd15080ca2f08e@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Comment (by simonpj): > Before Phab:D653, this case was handled by the `rec_nts` trick -- a newtype could be unwrapped only once. The problem with this trick is that it makes type inference a little wonky: canonicalization wasn't idempotent! For example, canonicalizing `Coercible skolem A` would get you `Coercible skolem [A]`. I don't agree. Looking at HEAD, I see {{{ can_eq_nc' rdr_env envs ev ReprEq ty1 _ ty2 ps_ty2 | Just (co, ty1') <- tcTopNormaliseNewTypeTF_maybe envs rdr_env ty1 = can_eq_newtype_nc rdr_env ev NotSwapped co ty1 ty1' ty2 ps_ty2 }}} This case simply won't fire on `Coercible skolem [A]`. The HEAD does not aggressively unwrap newtypes deep inside types, only immediately under a `Coercible`. And that's what we should do in the new version too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 15:47:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 15:47:22 -0000 Subject: [GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) In-Reply-To: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> References: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> Message-ID: <066.7e6ef126229d283345acb572ded453c4@haskell.org> #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: masterdezign | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: strange Operating System: Linux | closure type Type of failure: Runtime crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by masterdezign): Attaching the code. It is hard to determine the piece of code which fails, since it might take several hours until the problem appears. There is a clue what might be related to the problem, if you replace {{{ _ <- A.mapConcurrently calcWithMsg grid }}} in the main module (Simul.hs) with {{{ foldM calcWithMsg grid }}} then the program does not seem to fail (I am checking if that is always the case). Also, I am not sure if Data.Vector.Unboxed behaves well when using it unsafely (see Rk.hs). Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 16:01:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 16:01:05 -0000 Subject: [GHC] #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 In-Reply-To: <046.cfdb0dc1b2281b62f1e87667e0f4270a@haskell.org> References: <046.cfdb0dc1b2281b62f1e87667e0f4270a@haskell.org> Message-ID: <061.486f4f296e94d6343cc4045fa0a9000d@haskell.org> #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 -------------------------------------+------------------------------------- Reporter: stengel | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Other | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high * status: new => patch * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 16:02:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 16:02:20 -0000 Subject: [GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) In-Reply-To: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> References: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> Message-ID: <066.1b4f2c2727f30904da71deb845b960f8@haskell.org> #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: masterdezign | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: strange Operating System: Linux | closure type Type of failure: Runtime crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by masterdezign): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 16:53:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 16:53:01 -0000 Subject: [GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) In-Reply-To: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> References: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> Message-ID: <066.74f9daa2446fcf9023ac452c728d32b8@haskell.org> #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: masterdezign | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: strange Operating System: Linux | closure type Type of failure: Runtime crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): If there are unsafe operations being used, could you try with the safe versions and see if it still reproduces? Also, do you have any ways to reduce the repro case, or make it fail more quickly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 16:53:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 16:53:28 -0000 Subject: [GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) In-Reply-To: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> References: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> Message-ID: <066.f1187c1f63c743efd6d10d15b6ca393f@haskell.org> #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: masterdezign | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: strange Operating System: Linux | closure type Type of failure: Runtime crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 17:10:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 17:10:16 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.ffd5c80347b9aa0739d0d7159ce9a3a0@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Comment (by simonpj): Richard and I had a Skype chat. Conclusions: * We worked out what to do about Phab:D653, but there are lots of changes, and 7.10 is very close. * Edward's 117 coerces are already fixed, in 7.10 (see comment:14) * So we will not fix anything further in 7.10. * That leaves un-done the right fix for this ticket (hence some lurking bugs). * Also remaining un-done are #7788, #8550, #9554, and #10139. However none are blocking correct code from compiling and running. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 19:19:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 19:19:20 -0000 Subject: [GHC] #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" In-Reply-To: <045.33b56a4389644150958519a6a326156f@haskell.org> References: <045.33b56a4389644150958519a6a326156f@haskell.org> Message-ID: <060.989398611a2069eec8a4103684e37472@haskell.org> #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.9 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9963 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: #9360, #9259,#9823 => #9963 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 19:22:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 19:22:25 -0000 Subject: [GHC] #10156: Unable to coerce with flipped Coercible context Message-ID: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> #10156: Unable to coerce with flipped Coercible context -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1-rc2 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs coerce' :: Coercible a b => b -> a coerce' = coerce }}} doesn't compile, forcing workarounds like: {{{#!hs coerce' :: forall a b. Coercible a b => b -> a coerce' = coerce (id :: a -> a) }}} This arises in practice in several places in the `profunctors` package and `lens`. https://github.com/ekmett/profunctors/blob/1c3508e5274a0ed03765c569596a8fda8817ed56/src/Data/Profunctor/Unsafe.hs#L188 http://hackage.haskell.org/package/lens-4.8/docs/src/Control-Lens- Internal-Coerce.html#coerce%27 Ideally we'd be able to retire `coerce'` entirely and just use `coerce` in those contexts. The tricky part is of course avoiding infinite loops once you add symmetry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 19:25:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 19:25:58 -0000 Subject: [GHC] #9823: --show-iface panics with HEAD In-Reply-To: <048.f88fb01b9c0230c2f81d0f8e88c01d42@haskell.org> References: <048.f88fb01b9c0230c2f81d0f8e88c01d42@haskell.org> Message-ID: <063.5a2574772aee6399be887f0778c0818a@haskell.org> #9823: --show-iface panics with HEAD -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.9 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #9963 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: #9799 => #9963 Comment: Closing this as a duplicate of #9963, for which I have a fix. '--show-iface' is a mode flag, just like '--interactive' and '-e', and all usages of invalid (combinations of) mode flag(s) currently panic in HEAD. Note that the filename should come after the flag, and the error is: {{{ $ ghc-7.8.4 T9963.hi --show-iface ghc: on the commandline: missing argument for flag: --show-iface Usage: For basic information, try the `--help' option. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 20:16:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 20:16:31 -0000 Subject: [GHC] #10156: Unable to coerce with flipped Coercible context In-Reply-To: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> References: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> Message-ID: <060.173b175e73356576e2c3db1a5003e211@haskell.org> #10156: Unable to coerce with flipped Coercible context -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by glguy): * cc: glguy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 20:17:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 20:17:52 -0000 Subject: [GHC] #10156: Unable to coerce with flipped Coercible context In-Reply-To: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> References: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> Message-ID: <060.f763e7437fcf6b84f62ade511d16c694@haskell.org> #10156: Unable to coerce with flipped Coercible context -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I happen to be playing in this area this minute. Will try to fix this. But not for 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 20:26:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 20:26:58 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.82275df00b69493e749bbfdb27a2339e@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * related: #9799 => Comment: The function to change is called `setMode` in `ghc/Main.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 20:40:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 20:40:08 -0000 Subject: [GHC] #9906: Warning generated by hscpp code have unhelpful file names In-Reply-To: <044.c0b2b77cfbe1caa145f66f9718cb9575@haskell.org> References: <044.c0b2b77cfbe1caa145f66f9718cb9575@haskell.org> Message-ID: <059.8fb0fea7640fe4261f49ac4c4749ba8e@haskell.org> #9906: Warning generated by hscpp code have unhelpful file names -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 20:57:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 20:57:11 -0000 Subject: [GHC] #9963: GHCi panic with --print-libdir flag In-Reply-To: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> References: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> Message-ID: <063.308aa4bf72fa27ca32aec757d98a3c0a@haskell.org> #9963: GHCi panic with --print-libdir flag -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: thomie Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Driver | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | driver/T9963 | Blocking: | Differential Revisions: Phab:D730 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => driver/T9963 * differential: => Phab:D730 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 21:41:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 21:41:26 -0000 Subject: [GHC] #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available Message-ID: <045.a880c5ea8f0c0cc37611c17ef6bd7339@haskell.org> #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We seem to fill in the `--with-hscolour=` flag with an empty string, which causes a plain old build failure. Configure probably ought to fail if `HSCOLOUR_SRCS=YES` and there is no hscolours. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 21:41:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 21:41:31 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.ad3615d120434fb076ef736b24078cf2@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D731 Comment: I have a patch that does what I described in this ticket. I cannot reproduce the issue though because singletons fails with this {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.11.20150313 for x86_64-unknown-linux): StgCmmEnv: variable not found cobox_a1M03 local binds for: sConst sAsTypeOf sId %:++ sMap sFoldr %$ %$! $WLet_1627806145GoSym3KindInference $WLet_1627806145GoSym2KindInference $WLet_1627806145GoSym1KindInference ... sFlip1 sId1 sSeq1 a_r1Mg8 sF_s1MhC sG_s1MhD sA_1627806040_s1MhE Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I will create a new ticket for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 21:49:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 21:49:20 -0000 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found Message-ID: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> #10158: Panic compiling singletons: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `cabal install singletons` panics like this with HEAD: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.11.20150313 for x86_64-unknown-linux): StgCmmEnv: variable not found cobox_a1Job local binds for: sConst sAsTypeOf sId %:++ sMap sFoldr %$ %$! $WLet_1627796109GoSym3KindInference $WLet_1627796109GoSym2KindInference $WLet_1627796109GoSym1KindInference $WLet_1627796109GoSym0KindInference $WSeqSym1KindInference $WSeqSym0KindInference $WFlipSym2KindInference $WFlipSym1KindInference $WFlipSym0KindInference $WConstSym1KindInference $WConstSym0KindInference $WAsTypeOfSym1KindInference $WAsTypeOfSym0KindInference $WIdSym0KindInference $W:++$### $W:++$$### $WMapSym0KindInference $WMapSym1KindInference $WFoldrSym2KindInference $WFoldrSym1KindInference $WFoldrSym0KindInference $WLambda_1627796009Sym3KindInference $WLambda_1627796009Sym2KindInference $WLambda_1627796009Sym1KindInference $WLambda_1627796009Sym0KindInference $W:.$$$### $W:.$$### $W:.$### %$1 sAsTypeOf1 sConst1 sFlip1 sId1 sSeq1 a_r1JEg sF_s1JFN sG_s1JFO sA_1627796004_s1JFP Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 21:50:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 21:50:00 -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.a01d88214a61cfcd9e16ff3a185de768@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D727 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 21:51:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 21:51:01 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.5c0e05ec3de0dd7b3fce349a682df9e8@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Merged to `ghc-7.10` (via 6f46fe15af397d448438c6b93babcdd68dd78df8). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 13 21:55:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Mar 2015 21:55:38 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.60cce839926df580785038927fc9292c@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => normal * differential: => Phab:D652 * milestone: 7.10.1 => 7.12.1 Comment: (In light of the merge for the immediate fixes, I'm demoting this bug and pushing it to 7.12.1, in case the discussion wants to continue. Simon has also indicated he wants to continue working on this area and redo some things, so we can leave this ticket open for that.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 03:06:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 03:06:40 -0000 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found In-Reply-To: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> References: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> Message-ID: <062.dea08f6cf6e3294f5cd2394e97819edb@haskell.org> #10158: Panic compiling singletons: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => highest Comment: Yikes! I hope I'm not overstating the importance of my library to GHC, but this sounds serious. Is this reproducible on the 7.10 branch? If so, please set the milestone to 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 03:21:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 03:21:32 -0000 Subject: [GHC] #10156: Unable to coerce with flipped Coercible context In-Reply-To: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> References: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> Message-ID: <060.bbb6ad6c03f7a63176a6ec5f5ca885c1@haskell.org> #10156: Unable to coerce with flipped Coercible context -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => infoneeded Comment: I can't reproduce this with RC2. I wouldn't expect it to work in 7.8, but it should work in 7.10. (When I saw the ticket, I was quite surprised it didn't, as I thought the new solver handled symmetry!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 03:26:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 03:26:54 -0000 Subject: [GHC] #10156: Unable to coerce with flipped Coercible context In-Reply-To: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> References: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> Message-ID: <060.bd59559c87e18c05a30b24dab3cefc2b@haskell.org> #10156: Unable to coerce with flipped Coercible context -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by glguy): The feature request is that coerce' should not be necessary {{{ {-# LANGUAGE ScopedTypeVariables #-} module FeatureRequest where import Data.Coerce data Iso a b = Iso (a -> b) (b -> a) -- coerceIso :: Coercible a b => Iso a b -- desired coerceIso :: (Coercible a b, Coercible b a) => Iso a b -- required coerceIso = Iso coerce coerce coerce' :: forall a b. Coercible a b => b -> a coerce' = coerce (id :: a -> a) coerceIso' :: Coercible a b => Iso a b -- work around coerceIso' = Iso coerce coerce' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 03:58:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 03:58:11 -0000 Subject: [GHC] #10156: Unable to coerce with flipped Coercible context In-Reply-To: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> References: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> Message-ID: <060.241769f0c864a0bfa487c591c0f27818@haskell.org> #10156: Unable to coerce with flipped Coercible context -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): The following module compiles with 7.10 RC2 on my machine: {{{ module T10156 where import Data.Coerce data Iso a b = Iso (a -> b) (b -> a) coerceIso :: Coercible a b => Iso a b coerceIso = Iso coerce coerce }}} This looks like what you want. Is there something I'm missing here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 04:05:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 04:05:32 -0000 Subject: [GHC] #10156: Unable to coerce with flipped Coercible context In-Reply-To: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> References: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> Message-ID: <060.2545f5aeeb79f1fa75c1bae1471efe43@haskell.org> #10156: Unable to coerce with flipped Coercible context -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * status: infoneeded => closed * version: 7.10.1-rc2 => 7.8.4 * resolution: => invalid Comment: My mistake. It works in 7.10, but not 7.8. I was testing on the wrong box. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 04:20:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 04:20:41 -0000 Subject: [GHC] #7543: Constraint synonym instances In-Reply-To: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> References: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> Message-ID: <062.a02cdcb1c51238def5657cc5572e2147@haskell.org> #7543: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bheklilr): Has there been any more interest in this bug? I happened to run across it for the first time today with a problem essentially identical to @ekmett's. Any chance of it getting fixed one way or the other? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 05:27:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 05:27:42 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.87d99f9447c66184bb24112a11490859@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | simplCore/should_compile/T8848, | T8848a | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): It is possible that {{{ {-# RULE map2 = map2_spec #-} map2_spec :: (a->b->c)-> (Shape Z a )-> Shape Z b -> Shape Z c map2_spec = inline map2 }}} creates an infinite loop, because we end up with {{{ map2_spec = inline map2_spec }}} ? My program seems to hang after trying it, but GHC does not throw <>. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 05:29:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 05:29:38 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.e55ec9fe74f4e594b2474b8c6b6a71e5@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | simplCore/should_compile/T8848, | T8848a | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): @carter, were you able to get a workaround to work? We are experiencing the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 08:07:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 08:07:28 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.e7ae85b4cc1225cd71bbd01834a198c7@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"1b7f59769052fd8193c6acc561216e070d0ca335/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1b7f59769052fd8193c6acc561216e070d0ca335" Link temporary shared objects with `--no-as-needed` Some ELF link editors default to `--as-needed` and record only those libraries in DT_NEEDED tags that are needed to resolve undefined symbols in the shared object to be created. In Template Haskell we rely on all symbols that were defined in modules compiled so far to be available in the current temporary shared object. To prevent the link editor from dropping the DT_NEEDED tag for the previously linked temporary shared object we need to override the link editors default and specify `--no-as-needed` on the command line. This is for GNU ld and GOLD ld. This addresses #10110 TODO: regression test Reviewed By: hvr Differential Revision: https://phabricator.haskell.org/D731 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 08:11:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 08:11:15 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.590f3d6532ecb136ef66700bf004a513@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:7 Herbert Valerio Riedel ]: > In changeset:"1b7f59769052fd8193c6acc561216e070d0ca335/ghc" ...merged to ghc-7.10 via 3ea349220c3b72c97530c32c767e278570d497e4 So the only thing missing to close this ticket is a regression-test... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 08:43:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 08:43:24 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.ff8c3bce2d8d7dd5d9aabac550d653ee@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:25 simonpj]: ... will the known issues resulting from leaving some stuff deliberately unfixed in 7.10 make it into a release-note entry? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 08:57:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 08:57:55 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.623b6f900c4e10daf278545661549822@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | simplCore/should_compile/T8848, | T8848a | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): @yongqli A fix for this issue is supposed to be in 7.10. Please try your code with [http://downloads.haskell.org/~ghc/7.10.1-rc2/ release candidate 2]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 09:40:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 09:40:36 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.f68924946a2e783ff93f975023deb1b3@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | simplCore/should_compile/T8848, | T8848a | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): @thomie: We are stuck on GHC 7.8 for now :(. For what it's worth, I was able to work around the problem using the RULES method. I set the rule to fire after phase 1, so that "map2" would have already been inlined away, thus preventing an infinite loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 13:03:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 13:03:20 -0000 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found In-Reply-To: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> References: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> Message-ID: <062.11a0ff15bbfc37969b4df8cc4e776ff4@haskell.org> #10158: Panic compiling singletons: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by trommler): * failure: None/Unknown => Compile-time crash * milestone: => 7.12.1 Comment: The 7.10 branch is fine! I tried the 7.10 branch at changeset:d6f5b4cf7cf1e3a8946fe6a77ce68ec96baad8fd and singletons compiles. Setting milestone to 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 14:24:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 14:24:26 -0000 Subject: [GHC] #7543: Constraint synonym instances In-Reply-To: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> References: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> Message-ID: <062.e913c143fc5ddbe82eb2d0032a4304ea@haskell.org> #7543: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Building on comment:1, would it be easy to build this feature if the names of the methods have no scoping conflicts? That is, just do a normal (non- instance-style) lookup of method names, even in instances. If there is no ambiguity, proceed. If there is ambiguity, look at the instance head. If it's a class name, use that to disambiguate. Otherwise (if it's a synonym or bogus), report an error. That seems simple enough and without undue upheaval. Personally, I don't think disambiguating among multiply-in-scope names should hold this feature up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 18:04:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 18:04:36 -0000 Subject: [GHC] #8043: Feature Request : Qualified module exports In-Reply-To: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> References: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> Message-ID: <059.81e4b05ad6ece021782c7d5af9e86382@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: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by HairyDude): * cc: pwberry@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 19:26:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 19:26:26 -0000 Subject: [GHC] #1820: Windows segfault-catching only works for the main thread In-Reply-To: <047.7ca539e672ab08a35be7d52badf17eec@haskell.org> References: <047.7ca539e672ab08a35be7d52badf17eec@haskell.org> Message-ID: <062.51454eaa0907ead3bd29c8c1f3eb4273@haskell.org> #1820: Windows segfault-catching only works for the main thread -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Runtime System | Version: 6.8.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: 6079 | derefnull(ghci), divbyzero(ghci) | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: simonmar (added) * status: new => closed * resolution: => fixed * related: => 6079 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 19:26:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 19:26:52 -0000 Subject: [GHC] #6079: SEH exception handler not implemented on Win64 In-Reply-To: <044.31bc28f566675131a5a949cb43e64371@haskell.org> References: <044.31bc28f566675131a5a949cb43e64371@haskell.org> Message-ID: <059.f83942e42e05025004720ba914db9e34@haskell.org> #6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: derefnull, Related Tickets: | divbyzero | Blocking: | Differential Revisions: Phab:D691 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 19:28:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 19:28:23 -0000 Subject: [GHC] #6079: SEH exception handler not implemented on Win64 In-Reply-To: <044.31bc28f566675131a5a949cb43e64371@haskell.org> References: <044.31bc28f566675131a5a949cb43e64371@haskell.org> Message-ID: <059.eef46a0f7367eb16a4fa7f5233817569@haskell.org> #6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: derefnull, Related Tickets: 1820 | divbyzero | Blocking: | Differential Revisions: Phab:D691 -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => 1820 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 19:29:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 19:29:35 -0000 Subject: [GHC] #6079: SEH exception handler not implemented on Win64 In-Reply-To: <044.31bc28f566675131a5a949cb43e64371@haskell.org> References: <044.31bc28f566675131a5a949cb43e64371@haskell.org> Message-ID: <059.0eabfee5120d34c2975bc35791dc2e7a@haskell.org> #6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: derefnull, Related Tickets: #1820 | divbyzero | Blocking: | Differential Revisions: Phab:D691 -------------------------------------+------------------------------------- Changes (by Phyx-): * related: 1820 => #1820 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 19:29:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 19:29:54 -0000 Subject: [GHC] #1820: Windows segfault-catching only works for the main thread In-Reply-To: <047.7ca539e672ab08a35be7d52badf17eec@haskell.org> References: <047.7ca539e672ab08a35be7d52badf17eec@haskell.org> Message-ID: <062.e4c4ae93cc73c6600df9af3fc3ebec04@haskell.org> #1820: Windows segfault-catching only works for the main thread -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Runtime System | Version: 6.8.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #6079 | derefnull(ghci), divbyzero(ghci) | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * related: 6079 => #6079 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 19:36:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 19:36:00 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.3a048cf03df35b6115081563e62d00f4@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: I was only planning on rewriting it in Haskell. Though if any interface changes are required I would be happy to incorporate them during the rewrite. I still need to figure out what this does and where it's called before I get started. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 20:19:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 20:19:16 -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.5cc9d29c1ddd8ae975ec18835e2132d2@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.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 Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx-, core-libraries-committee@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 14 21:47:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Mar 2015 21:47:08 -0000 Subject: [GHC] #7934: usleep hangs, no threads In-Reply-To: <046.d121f779cb2c7e3c2c6772b604e9540c@haskell.org> References: <046.d121f779cb2c7e3c2c6772b604e9540c@haskell.org> Message-ID: <061.45000f27c0f9614a6fd1bab752a6f05b@haskell.org> #7934: usleep hangs, no threads -------------------------------------+------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 1156 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gelisam): Yes, it still occurs with ghc 7.8.3 on my OS X 10.6.8 machine. However, it does not occur with ghc 7.8.2 on my OS X 10.9.2 machine, so it's probably an OS X bug which since got fixed. I think we can finally close this issue :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 15 01:00:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Mar 2015 01:00:56 -0000 Subject: [GHC] #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! Message-ID: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! -----------------------------------------+--------------------------------- Reporter: jamshid | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- I know this sounds pretty nuts, but compiling using ghc, via "cabal build" often suddenly reboots my computer (not the slow "please save your settings" type, but the sudden harsh sound of a relay click and immediate blackness followed by the BIOS screen). This happens somewhat randomly, although the probability of it occurring definitely goes up with a larger codebase. Beyond a certain size, it is pretty much guaranteed to happen. This could possibly have something to do with faulty hardware.... but I am not so sure because.... 1. The reboot only occurs when compiling with GHC. Nothing else (movie watching, compiling with gcc, processing audio, etc) causes this to happen. Furthermore the reboot is as likely to happen on a computer with no other program running as one with tons of background stuff, the ghc build is the only factor. Other than this bug, it is a powerful and reliable machine. 2. The reboot only occurs when I type "cabal build", not "cabal install", even if the project has just been cleaned. If it were just an overheating microprocessor, I would expect the problem to exist in both cases. In fact, as long as I don't type in "cabal build" exactly, I can download large projects (like the ghc compiler source code itself) and build them without a problem. I am even at a loss of what info to give you. I would be happy to supply whatever info you request and even do some debugging. For starters, here is my configuration.... Ubuntu 14.10 Kernel version 3.16.0-31-generic ghc version 7.8.4 cabal-install version 1.22.0.1 using version 1.22.1.1 of the Cabal library CPU- Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 16GB RAM Motherboard Gigabyte GA-Z87-D3HP I am not sure if logs will be of any use, because I am pretty sure that the sudden nature of the reboot prevents any info from being output.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 15 06:23:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Mar 2015 06:23:55 -0000 Subject: [GHC] #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL Message-ID: <048.55a9661044b934d281580d4eba633a8a@haskell.org> #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Keywords: :sprint | Operating System: Unknown/Multiple thunk evaluation | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Wanted to use :sprint to help learners visualise thunk evaluation behavior in their data. Ran into some behaviors that a few people I checked with didn't have a good explanation for. I couldn't find anything in the user guide to explain this. I don't think it technically violates Haskell Report requirements, but it makes :sprint considerably less useful if you're teaching somebody non-strictness. Examples with code in the REPL: {{{ Prelude> let x = [1, 2, 3] Prelude> :sprint x x = _ Prelude> :t x x :: Num t => [t] -- this makes sense so far. Prelude> let x = [1, 2, 3 :: Integer] Prelude> :sprint x x = [1,2,3] -- errr, what? Prelude> let x = Just (1 :: Integer) Prelude> :sprint x x = Just 1 Prelude> let just = Just Prelude> let x = just (1 :: Integer) Prelude> :sprint x x = _ Prelude> let x = Just (undefined :: Integer) Prelude> :sprint x x = Just _ Prelude> let x = just (undefined :: Integer) Prelude> :sprint x x = _ Prelude> let x = [1, 2, 3 :: Integer] Prelude> let y = x Prelude> :sprint y y = [1,2,3] Prelude> let x = 1 : 2 : (3 :: Integer) : [] Prelude> :sprint x x = [1,2,3] Prelude> let x = [1] ++ [2] ++ [(3 :: Integer)] Prelude> :sprint x x = _ Prelude> let y = (:) Prelude> let x = 1 `y` (2 `y` ((3 :: Integer) `y` [])) Prelude> :sprint x x = _ Prelude> x [1,2,3] Prelude> :sprint x x = [1,2,3] }}} So the behavior here seems to be: Constructors used directly in the construction of data and are not passed functions (including polymorphic vals awaiting concrete instances)/bottoms are immediately evaluated Example, but with loading data from a file: Contents of the file: {{{ x :: Num a => [a] x = [1, 2, 3] }}} GHCi session: {{{ Prelude> :t x x :: Num a => [a] Prelude> :sprint x x = _ Prelude> x [1,2,3] Prelude> :sprint x x = _ }}} Then when x is loaded from a file, but has a different type: {{{ Prelude> :t x x :: [Integer] Prelude> :sprint x x = _ Prelude> head x 1 Prelude> :sprint x x = [1,2,3] }}} Now, this is a bit confusing. Earlier I was able to get :sprint to return [1, _, _] when I evaluated head x, but a couple hours later when I went to write this ticket, I couldn't reproduce that behavior. Is there documentation that explains: 1. Why data is shown as having been evaluated at time of declaration (seemingly) by :sprint when it's defined in the GHCi 2. Why declaring code in GHCi and loading it from a file behaves differently with :sprint (I considered let expression in the implicit GHCi do-block...couldn't find anything to explain this) 3. Why evaluating 'head x' forces the other values as well Are any of these behaviors a bug? If not, are they documented anywhere? Is the "eager" treatment of constructors in GHCi a performance thing? That seems strange given I didn't have -fobject-code turned on. :sprint not demonstrating semantics that match what I expect from a non- strict language hinders its utility as a teaching tool and means the only robust option for learners that I can find is testing evaluation with bottom values. {{{ -- So that you know i picked "7.8.4" as the version consciously [callen at atlantis ~/Work/fpbook]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 [callen at atlantis ~/Work/fpbook]$ ghci --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 15 06:26:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Mar 2015 06:26:23 -0000 Subject: [GHC] #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL In-Reply-To: <048.55a9661044b934d281580d4eba633a8a@haskell.org> References: <048.55a9661044b934d281580d4eba633a8a@haskell.org> Message-ID: <063.0dc143b1644b552cb7a4a874b952b40d@haskell.org> #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: :sprint Operating System: Unknown/Multiple | thunk evaluation non-strictness Type of failure: Incorrect result | laziness runtime ghci repl at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bitemyapp): * keywords: :sprint thunk evaluation => :sprint thunk evaluation non- strictness laziness runtime ghci repl -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 15 06:27:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Mar 2015 06:27:17 -0000 Subject: [GHC] #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL In-Reply-To: <048.55a9661044b934d281580d4eba633a8a@haskell.org> References: <048.55a9661044b934d281580d4eba633a8a@haskell.org> Message-ID: <063.842a04dbf500903742e93d2ccf3e2e2e@haskell.org> #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: :sprint Operating System: Unknown/Multiple | thunk evaluation non-strictness Type of failure: Incorrect result | laziness runtime ghci repl at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bitemyapp: Old description: > Wanted to use :sprint to help learners visualise thunk evaluation > behavior in their data. Ran into some behaviors that a few people I > checked with didn't have a good explanation for. I couldn't find anything > in the user guide to explain this. I don't think it technically violates > Haskell Report requirements, but it makes :sprint considerably less > useful if you're teaching somebody non-strictness. > > Examples with code in the REPL: > > {{{ > Prelude> let x = [1, 2, 3] > Prelude> :sprint x > x = _ > Prelude> :t x > x :: Num t => [t] > -- this makes sense so far. > > Prelude> let x = [1, 2, 3 :: Integer] > Prelude> :sprint x > x = [1,2,3] > -- errr, what? > > Prelude> let x = Just (1 :: Integer) > Prelude> :sprint x > x = Just 1 > > Prelude> let just = Just > Prelude> let x = just (1 :: Integer) > Prelude> :sprint x > x = _ > > Prelude> let x = Just (undefined :: Integer) > Prelude> :sprint x > x = Just _ > > Prelude> let x = just (undefined :: Integer) > Prelude> :sprint x > x = _ > > Prelude> let x = [1, 2, 3 :: Integer] > Prelude> let y = x > Prelude> :sprint y > y = [1,2,3] > > Prelude> let x = 1 : 2 : (3 :: Integer) : [] > Prelude> :sprint x > x = [1,2,3] > Prelude> let x = [1] ++ [2] ++ [(3 :: Integer)] > Prelude> :sprint x > x = _ > > Prelude> let y = (:) > Prelude> let x = 1 `y` (2 `y` ((3 :: Integer) `y` [])) > Prelude> :sprint x > x = _ > Prelude> x > [1,2,3] > Prelude> :sprint x > x = [1,2,3] > }}} > > So the behavior here seems to be: > > Constructors used directly in the construction of data and are not passed > functions (including polymorphic vals awaiting concrete > instances)/bottoms are immediately evaluated > > Example, but with loading data from a file: > > Contents of the file: > > {{{ > x :: Num a => [a] > x = [1, 2, 3] > }}} > > GHCi session: > > {{{ > Prelude> :t x > x :: Num a => [a] > > Prelude> :sprint x > x = _ > > Prelude> x > [1,2,3] > > Prelude> :sprint x > x = _ > }}} > > Then when x is loaded from a file, but has a different type: > > {{{ > Prelude> :t x > x :: [Integer] > Prelude> :sprint x > x = _ > Prelude> head x > 1 > Prelude> :sprint x > x = [1,2,3] > }}} > > Now, this is a bit confusing. Earlier I was able to get :sprint to return > [1, _, _] when I evaluated head x, but a couple hours later when I went > to write this ticket, I couldn't reproduce that behavior. > > Is there documentation that explains: > > 1. Why data is shown as having been evaluated at time of declaration > (seemingly) by :sprint when it's defined in the GHCi > > 2. Why declaring code in GHCi and loading it from a file behaves > differently with :sprint (I considered let expression in the implicit > GHCi do-block...couldn't find anything to explain this) > > 3. Why evaluating 'head x' forces the other values as well > > Are any of these behaviors a bug? If not, are they documented anywhere? > Is the "eager" treatment of constructors in GHCi a performance thing? > That seems strange given I didn't have -fobject-code turned on. > > :sprint not demonstrating semantics that match what I expect from a non- > strict language hinders its utility as a teaching tool and means the only > robust option for learners that I can find is testing evaluation with > bottom values. > > {{{ > -- So that you know i picked "7.8.4" as the version consciously > > [callen at atlantis ~/Work/fpbook]$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.8.4 > > [callen at atlantis ~/Work/fpbook]$ ghci --version > The Glorious Glasgow Haskell Compilation System, version 7.8.4 > }}} New description: Wanted to use :sprint to help learners visualise thunk evaluation behavior in their data. Ran into some behaviors that a few people I checked with didn't have a good explanation for. I couldn't find anything in the user guide to explain this. I don't think it technically violates Haskell Report requirements, but it makes :sprint considerably less useful if you're teaching somebody non-strictness. Examples with code in the REPL: {{{ Prelude> let x = [1, 2, 3 :: Integer] Prelude> :sprint x x = [1,2,3] -- errr, what? Prelude> let x = Just (1 :: Integer) Prelude> :sprint x x = Just 1 Prelude> let just = Just Prelude> let x = just (1 :: Integer) Prelude> :sprint x x = _ Prelude> let x = Just (undefined :: Integer) Prelude> :sprint x x = Just _ Prelude> let x = just (undefined :: Integer) Prelude> :sprint x x = _ Prelude> let x = [1, 2, 3 :: Integer] Prelude> let y = x Prelude> :sprint y y = [1,2,3] Prelude> let x = 1 : 2 : (3 :: Integer) : [] Prelude> :sprint x x = [1,2,3] Prelude> let x = [1] ++ [2] ++ [(3 :: Integer)] Prelude> :sprint x x = _ Prelude> let y = (:) Prelude> let x = 1 `y` (2 `y` ((3 :: Integer) `y` [])) Prelude> :sprint x x = _ Prelude> x [1,2,3] Prelude> :sprint x x = [1,2,3] }}} So the behavior here seems to be: Constructors used directly in the construction of data and are not passed functions (including polymorphic vals awaiting concrete instances)/bottoms are immediately evaluated Example, but with loading data from a file: Contents of the file: {{{ x :: Num a => [a] x = [1, 2, 3] }}} GHCi session: {{{ Prelude> :t x x :: Num a => [a] Prelude> :sprint x x = _ Prelude> x [1,2,3] Prelude> :sprint x x = _ }}} Then when x is loaded from a file, but has a different type: {{{ Prelude> :t x x :: [Integer] Prelude> :sprint x x = _ Prelude> head x 1 Prelude> :sprint x x = [1,2,3] }}} Now, this is a bit confusing. Earlier I was able to get :sprint to return [1, _, _] when I evaluated head x, but a couple hours later when I went to write this ticket, I couldn't reproduce that behavior. Is there documentation that explains: 1. Why data is shown as having been evaluated at time of declaration (seemingly) by :sprint when it's defined in the GHCi 2. Why declaring code in GHCi and loading it from a file behaves differently with :sprint (I considered let expression in the implicit GHCi do-block...couldn't find anything to explain this) 3. Why evaluating 'head x' forces the other values as well Are any of these behaviors a bug? If not, are they documented anywhere? Is the "eager" treatment of constructors in GHCi a performance thing? That seems strange given I didn't have -fobject-code turned on. :sprint not demonstrating semantics that match what I expect from a non- strict language hinders its utility as a teaching tool and means the only robust option for learners that I can find is testing evaluation with bottom values. {{{ -- So that you know i picked "7.8.4" as the version consciously [callen at atlantis ~/Work/fpbook]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 [callen at atlantis ~/Work/fpbook]$ ghci --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 15 07:41:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Mar 2015 07:41:14 -0000 Subject: [GHC] #10115: Unable to run cabal haddock --hoogle on GHC 7.10 In-Reply-To: <047.decd164805e4d10458a8e3160e406e34@haskell.org> References: <047.decd164805e4d10458a8e3160e406e34@haskell.org> Message-ID: <062.b777d8166ba0cca9c8580fb75a12f6bc@haskell.org> #10115: Unable to run cabal haddock --hoogle on GHC 7.10 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"cbc7103044cff890c9916c8418b2f93cbece9b83/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cbc7103044cff890c9916c8418b2f93cbece9b83" Update Haddock submodule This pulls in a cherry-picked commit adding support for the new `--package-name` and `--package-version` flags and thus helps addressing #10115. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 15 07:41:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Mar 2015 07:41:15 -0000 Subject: [GHC] #10115: Unable to run cabal haddock --hoogle on GHC 7.10 In-Reply-To: <047.decd164805e4d10458a8e3160e406e34@haskell.org> References: <047.decd164805e4d10458a8e3160e406e34@haskell.org> Message-ID: <062.5fc160e83088af51af279d7d293f8d43@haskell.org> #10115: Unable to run cabal haddock --hoogle on GHC 7.10 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"14b78eb7390dcf78c104501f4c24ac013a70a766/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="14b78eb7390dcf78c104501f4c24ac013a70a766" Update Cabal submodule to latest 1.22.1.2 snapshot This addresses the Cabal side of #10115 as this pulls in the following two commits: > Make sure to pass the package key to ghc > Haddock: Use --package-{name|version} when available }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 15 16:10:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Mar 2015 16:10:44 -0000 Subject: [GHC] #10161: GHC does not relink if a library's code changed Message-ID: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> #10161: GHC does not relink if a library's code changed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Test case for reproducing: https://github.com/nh2/ghc-relinking-avoidance- bug/ ---- {{{myexe}}} is an executable that depends on {{{mylib}}}, whose {{{myfun = putStrLn "output 1"}}}. If we install {{{mylib}}}, compile {{{myexe}}}, then change mylib's code to {{{myfun = putStrLn "output 2"}}}, re-install it, and then compile {{{myexe}}}, then GHC does not notice that the library code changed. It avoids re-linking myexe, with the result that the program prints {{{output 1}}} when you told it to compile against code that prints {{{output 2}}}. ---- Note that I had to use {{{NOINLINE myfun}}} to trigger the bug, since otherwise {{{myfun}}}'s code would have ended up in the interface file, thus changing the package ID, which naturally forces GHC to relink (even re-compile). With the {{{NOINLINE}}}, the package IDs of the two different versions of {{{myfun}}} are completely identical. I think that is correct, since the package ID only hashes the API and ABI, not the actual implementation, right? How does GHC decide when to relink? I think in the present case, it doesn't notice that the object/archive file of the library changed. Does it check that somehow? Just looking at API and API can't be enough to make a decision for linking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 01:04:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 01:04:18 -0000 Subject: [GHC] #9056: --make paths are not deduplicated In-Reply-To: <054.6d9311fc6ac4a797c0df6e46e05c1bcb@haskell.org> References: <054.6d9311fc6ac4a797c0df6e46e05c1bcb@haskell.org> Message-ID: <069.b6ac32ac1daef0456e38f746b5c9ff5c@haskell.org> #9056: --make paths are not deduplicated -------------------------------------+------------------------------------- Reporter: evincarofautumn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): I was working on a patch for this (attached, unfinished), but now don't think there's actually a bug here. I find the current error message quite clear, and think that it can be expected from a build system or the user not to supply the same filename twice. Please do reopen if you disagree, perhaps as a feature request. Fwiw: gcc doesn't seem to deduplicate input filenames either, giving a similar error message. {{{ $ cat test.c int main(void) { return 0; } $ gcc test.c test.c /tmp/ccL0QwIZ.o: In function `main': test.c:(.text+0x0): multiple definition of `main' /tmp/ccxMTZBK.o:test.c:(.text+0x0): first defined here collect2: error: ld returned 1 exit status }}} If we do want this: It is not as simple as just deduplicating filenames. For starters, comparing paths with (==) returns False for `./foo` and `foo`, so `System.FilePath.equalFilePaths` should be used. But what about relative vs absolute paths? What about `Main` and `Main.hs`, are they the same? What about `Main.lhs` and `Main.hs`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 01:09:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 01:09:09 -0000 Subject: [GHC] #9056: --make paths are not deduplicated In-Reply-To: <054.6d9311fc6ac4a797c0df6e46e05c1bcb@haskell.org> References: <054.6d9311fc6ac4a797c0df6e46e05c1bcb@haskell.org> Message-ID: <069.c45b9a085052f0e77f3cc9e3856db41e@haskell.org> #9056: --make paths are not deduplicated -------------------------------------+------------------------------------- Reporter: evincarofautumn | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Driver | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * type: bug => feature request * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 12:18:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 12:18:14 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.608a33b0ab7c999060222b62b113ce9b@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): It looks like the simplifier does not preserve correctness of demand information. After the worker-wrapper pass, I have this fragment of code {{{ of m'_axp [Dmd=] { Array ipv_s1i9 [Dmd=] -> Main.Machine (gstep m'_axp) t_axr } }}} Here, the demand info on `ipv_s1i9` is correct, it is indeed unused. However, after one iteration of simplifier pass, it becomes: {{{ of m'_axp [Dmd=] { Array ipv_s1i9 [Dmd=] -> (# \ (w_s3Ix :: Int) -> case w_s3Ix of _ [Occ=Dead] { GHC.Types.I# ww_X3IZ -> case $wgstep_s3II ipv_s1i9 ww_X3IZ of _ [Occ=Dead] { (# ww_X3Ja, ww_X3Jc #) -> Main.Machine ww_X3Ja ww_X3Jc } }, ww_s3IA #) }}} Now `ipv_s1i9` is referenced and will be used, but its usage information has not been updated. I've found the note `[Case alternative occ info]` in Simplify.hs, which explains why the occurrence info on case-bound variables should be zapped. I tried zapping the usage info as well as the occurrence info here (patch attached). It seems to compile `repeated2.hs` fine, but I'm not sure about a few points: * Is the approach right? i.e. is it a good idea to manually modify the usage info in the simplifier? * Probably the patch is overly conservative, in that it zaps the strictness info as well as the usage info. However, how hard should I try to preserve information? For example, should the code have a special case for when the case binder and the scrutinee are both marked unused? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 14:45:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 14:45:11 -0000 Subject: [GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot In-Reply-To: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> References: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> Message-ID: <057.310c576308f615bd368c6cf02e1d3275@haskell.org> #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: @nh2: could you please attach an example `Myfile.hs` and `Other.hs`? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 14:56:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 14:56:27 -0000 Subject: [GHC] #10156: Unable to coerce with flipped Coercible context In-Reply-To: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> References: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> Message-ID: <060.841ddd0c28a91e4eb1ec78fd7791e4df@haskell.org> #10156: Unable to coerce with flipped Coercible context -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"817d2c3436a99d998c79c5f9755c03aa21ced32c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="817d2c3436a99d998c79c5f9755c03aa21ced32c" Test Trac #10156 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 14:57:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 14:57:10 -0000 Subject: [GHC] #10156: Unable to coerce with flipped Coercible context In-Reply-To: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> References: <045.50a4e0884385a2e8044f3be0df4b6244@haskell.org> Message-ID: <060.bd4172386e1b9411cef6acda272f5ce2@haskell.org> #10156: Unable to coerce with flipped Coercible context -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | typecheck/should_compile/T10156 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T10156 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 15:02:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 15:02:32 -0000 Subject: [GHC] #10162: Add unicode syntax for banana brackets Message-ID: <045.f7ad53896487f5f5496f96174e92dff7@haskell.org> #10162: Add unicode syntax for banana brackets -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- While there is a ?pretty? unicode alternative available for ?- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 15:07:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 15:07:25 -0000 Subject: [GHC] #7543: Constraint synonym instances In-Reply-To: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> References: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> Message-ID: <062.9c093638072ff7250f7a4b462a76b8d3@haskell.org> #7543: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes we could do as Richard suggests. It'd be one more thing to explain in the user manual. And I'm a little suspicious, because now if I'm hunting for instances of some class I need to take synonyms into account. I grant that we already allow ''type'' synonyms in the instance head, and that too makes hunting for instances harder in a similar way. Are these disadvantages outweighed by the advantages? Do more than two people want this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 15:18:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 15:18:16 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.1911aaf4952745bd5012416fc096d7d8@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | simplCore/should_compile/T8848, | T8848a | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I don't think that comment:12 has much to do with this ticket although it's hard to tell without a repro case. It's easy to make GHC diverge using rules. Most crudely {{{ {-# RULE map2 = map2 #-} }}} would do it, by making the rule fire repeatedly. Your code looks sort of like that, although as I say it is hard to tell. You can see more of what is happening with `-ddump-inlinings` and `-ddump- rule-firings`. For now I think this probably a user error. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 15:36:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 15:36:53 -0000 Subject: [GHC] #7543: Constraint synonym instances In-Reply-To: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> References: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> Message-ID: <062.93b4102fba6a2312c8595578abcc83f7@haskell.org> #7543: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): The other thing we could do is support this feature at synonym-definition time. When defining a type synonym such that the head of the RHS is a class, record this fact in the `TyCon` and corresponding iface info. If such a synonym appears as the head of an instance declaration, we use this tidbit to do the name lookup. This would be easier to explain, at least, and wouldn't require much upheaval either. Actually, this is probably simpler than my idea in comment:7. About looking up instances: we really need to move beyond `grep` for this sort of thing! Of course, I exclusively use `grep` for this sort of thing... because I don't have a better option to hand. But that's a story for another day. In the meantime, worrying about obfuscation via synonyms is valid, but also not something that (I believe) should hold this up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 15:40:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 15:40:40 -0000 Subject: [GHC] #7543: Constraint synonym instances In-Reply-To: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> References: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> Message-ID: <062.1f34f999b970080588b9369f43f0b5a8@haskell.org> #7543: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > This would be easier to explain, at least, and wouldn't require much upheaval either. Actually, this is probably simpler than my idea in comment:7. I don't think so. {{{ type C a = X a Num type X a b = b a }}} I really don't want to put enough cleverness in the renamer to expand type synonyms on the fly. Let's see how keen our users are. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 15:50:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 15:50:23 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.c83fad4e6714a79f8bbb0054f30ff06e@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:26 hvr]: > Replying to [comment:25 simonpj]: > > ... will the known issues resulting from leaving some stuff deliberately unfixed in 7.10 make it into a release-note entry? I think this is reasonable. I've written up such a note at Phab:D735. O, you with ghc-7.10 access, please merge! Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 16:33:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 16:33:28 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.129f8e5e0ec557c0b4f6df6d0deee0af@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Comment (by goldfire): I've hit a real roadblock here and am stalled. See [wiki:Design/NewCoercibleSolver/V2 this wiki page]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 17:39:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 17:39:28 -0000 Subject: [GHC] #9963: GHCi panic with --print-libdir flag In-Reply-To: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> References: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> Message-ID: <063.1687e61a63cbe75d1ccc19ab618d1b30@haskell.org> #9963: GHCi panic with --print-libdir flag -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: thomie Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Driver | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | driver/T9963 | Blocking: | Differential Revisions: Phab:D730 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5166ee94e439375a4e6acb80f88ec6ee65476bbd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5166ee94e439375a4e6acb80f88ec6ee65476bbd" Dont call unsafeGlobalDynFlags if it is not set Parsing of static and mode flags happens before any session is started, i.e., before the first call to 'GHC.withGhc'. Therefore, to report errors for invalid usage of these two types of flags, we can not call any function that needs DynFlags, as there are no DynFlags available yet (unsafeGlobalDynFlags is not set either). So we always print "on the commandline" as the location, which is true except for Api users, which is probably ok. When reporting errors for invalid usage of dynamic flags we /can/ make use of DynFlags, and we do so explicitly in DynFlags.parseDynamicFlagsFull. Before, we called unsafeGlobalDynFlags when an invalid (combination of) flag(s) was given on the commandline, resulting in panics (#9963). This regression was introduced in 1d6124de. Also rename showSDocSimple to showSDocUnsafe, to hopefully prevent this from happening again. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D730 GHC Trac Issues: #9963 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 17:40:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 17:40:49 -0000 Subject: [GHC] #9963: GHCi panic with --print-libdir flag In-Reply-To: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> References: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> Message-ID: <063.3cf45616710ec01d24f32e68a388beee@haskell.org> #9963: GHCi panic with --print-libdir flag -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: thomie Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Driver | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | driver/T9963 | Blocking: | Differential Revisions: Phab:D730 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 18:39:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 18:39:56 -0000 Subject: [GHC] #7543: Constraint synonym instances In-Reply-To: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> References: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> Message-ID: <062.e13c24f71920b051deb23239d3119f7c@haskell.org> #7543: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bheklilr): I don't have a particular attachment to being able to do this, my biggest concern is that it's somewhat inconsistent behavior. If a constraint isn't a class, then it shouldn't be possible to make an instance of it. Or we should allow all constraints to be instantiated as classes. This could lead to some interesting problems to have to solve, such as when two constraints are used that could have overlapping names {{{ module C1 where class C1 a where c :: a -> a }}} ---- {{{ module C2 where class C2 a where c :: a -> a }}} ---- {{{ module C where import C1 import C2 type Cs a = (C1 a, C2 a) instance Cs Int where C1.c = pred C2.c = succ }}} This won't work currently because you can't use qualified names in a binding position, but without the qualification you can't distinguish between the different `c` methods on the classes. I also can't say I'm a fan of having multiple instances defined in the same block. For example, the following would bother me {{{ newtype MyInt = MyInt Int type OrdNum a = (Num a, Ord a) instance OrdNum MyInt where compare (MyInt x) (MyInt y) = compare x y fromInteger = MyInt ... -- Results in -- instance Num MyInt -- instance Ord MyInt }}} Considering that the argument for being able use constraints like this is that it would slightly improve the usability of a handful of libraries, I'm personally leaning towards a fix that would simply disallow instancing anything that is not a class. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 16 21:50:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Mar 2015 21:50:40 -0000 Subject: [GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot In-Reply-To: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> References: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> Message-ID: <057.77f0fddc7aec970439f0d8cb81fe3c8e@haskell.org> #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nh2): * status: infoneeded => new Comment: Oh right, here it is: https://github.com/nh2/ghc-osuf-lost-character-regression -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 02:44:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 02:44:10 -0000 Subject: [GHC] #10163: Export typeRepKinds in Data.Typeable Message-ID: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> #10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc3 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{TypeRep}}} has a {{{[KindRep]}}} field internally, {{{Data.Typeable}}} should export {{{typeRepKinds}}} (alongside {{{typeRepTyCon}}} and {{{typeRepArgs}}}, which are currently exported) to allow users to access it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 03:26:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 03:26:36 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess (was: ghc 7.8.4 and 7.10 fail to build on aarch64) In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.e3a50d5c3ae331b766496f0f57327b22@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * priority: normal => high * failure: None/Unknown => Installing GHC failed Comment: Also happens with ghc-7.11.20150316 (yesterday's head of git master). Note: {{{ $ rpmbuild/BUILDROOT/ghc-7.11.20150316-0.1.fc21.aarch64/usr/lib64/ghc-7.11.20150316/bin /ghc-pkg --version GHC package manager version 7.11.20150316 $ }}} vs {{{ $ echo $(rpmbuild/BUILDROOT/ghc-7.11.20150316-0.1.fc21.aarch64/usr/lib64/ghc-7.11.20150316/bin /ghc-pkg --version) $ }}} !! So somehow subprocess IO seems to be affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 08:37:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 08:37:15 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.a3df7827f98156de2c1b597901db2ad3@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by darchon): 7.10-RC3 was just released, but this bug is still not fixed. Is the fix in HEAD? Will it be fixed in 7.10.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 08:49:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 08:49:08 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.48e66fb6d0defe2d6f0b7b476c3becf7@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Rats. I wish you'd highlighted this earlier. We've been advertising 7.10.1 for ages, with a clearly stated list of priorities on the [https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 7.10.1 status page]. It says that we'll only fix "highest" priority bugs. If you care deeply about things, it's a good idea to monitor the status page and bid to have it promoted to "highest". I'm not sure how to proceed now. I don't know how hard it is to fix. I don't know how mission-critical it is to how many people. More info on the latter would be helpful. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 09:08:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 09:08:24 -0000 Subject: [GHC] #10163: Export typeRepKinds in Data.Typeable In-Reply-To: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> References: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> Message-ID: <065.c9fb61936964cfb01625247770d46d7e@haskell.org> #10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Maybe. In the future I'm not sure we'll distinguish between kind and type arguments. I think a better solution would be for `typeRepArgs` to return the kind ''and'' type arguments. In any case I mostly think you shouldn't be decomposing `TypeRep` at all. Are you? What's your use-case? Simon'''''' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 09:12:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 09:12:43 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.ff40570b37ee8997295ab874c1c18788@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by darchon): It is not mission critical for me. I just encountered a piece of code of my own that works on 7.8.4, but complains (perhaps rightfully so) about ambiguous types in 7.10.1-rc3. I just hit on this issue when googling the error message, and my question was merely if a fix in HEAD slipped through, and did not make it in 7.10.1-rc3. Christiaan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 09:14:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 09:14:26 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.2427119f038e80321ca7970cce1c8a19@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): OK good, thanks! (And that accounts for why you didn't yell.) Let's see if it's mission critical for anyone else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 09:39:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 09:39:36 -0000 Subject: [GHC] #10099: cabal install broken with ghc 7.10.1-rc2 In-Reply-To: <047.602c37795a358463eb57e7ffa8e992ef@haskell.org> References: <047.602c37795a358463eb57e7ffa8e992ef@haskell.org> Message-ID: <062.c536e1bc85ca20337aca5c85e9c9dae9@haskell.org> #10099: cabal install broken with ghc 7.10.1-rc2 -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Package system | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): I just installed 7.10.1-RC3 with cabal-install from the Cabal repo (1.22 branch) and I can confirm this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 11:20:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 11:20:30 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting Message-ID: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 11:24:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 11:24:05 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.443f8c86619444a3288c3294fcf0d42f@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): In [changeset:"5258566ee5c89aa757b0cf1433169346319c018f/ghc"]: {{{ commit 5258566ee5c89aa757b0cf1433169346319c018f Author: Thomas Miedema <> Date: Fri Mar 6 21:55:36 2015 +0100 Cleanup test framework string formatting * Use format strings instead of string concatenation. * Wrap `config.compiler`, `config.hpc` etc. in quotes in `mk/test.mk`, so we don't have to in .T scripts and driver/testlib.py. Update hpc submodule (test cleanup) Reviewers: austin Differential Revision: https://phabricator.haskell.org/D718 }}} Merged to 7.10 in dde3a2378e3961f7eed82d07d2f1e904878cc2b0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 11:26:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 11:26:23 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.c3714378cf978d00b39e89fa98c93343@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): In cc07a0ba64b554ffd1ff85757b02cd79d30ed57a/ghc: {{{ commit cc07a0ba64b554ffd1ff85757b02cd79d30ed57a Author: Thomas Miedema Date: Fri Mar 13 21:07:15 2015 +0100 Move the function strip_quotes to testutil.py If one runs the testsuite with a profiling compiler, during the import of `testlib.py`, `testlib.py` sets the global variable `gs_working`. To do so, it executes a few statements which require the function `strip_quotes` to be in scope. But that function only gets defined at the very end of testlib.py. This patch moves the definition of `strip_quotes` to testutil.py, which is imported at the very top of testlib.py. This unbreaks the nightly builders. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D728 }}} Merged to 7.10 in 65753a9d3414d52b9a97cb23e3c8cff84f7528e5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 11:28:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 11:28:42 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.e5b81a8e0ee3675ad0bd975379f47fac@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): In beee618c4ab8f725acd4dce3ef8a0d4ce84bb6ec/ghc: {{{ commit beee618c4ab8f725acd4dce3ef8a0d4ce84bb6ec Author: Thomas Miedema Date: Sun Mar 15 21:06:39 2015 +0100 Fix testsuite driver for a profiling compiler This should have been part of commit 5258566ee5c8, to allow expansion of '{hp2ps}' in a command string to `config.hp2ps`. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D734 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 11:29:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 11:29:47 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.9dc17e37923cf99b05244d926abba3b7@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): In 9987c66d7c3a1186acb5a32e92cd6846d71987a5/ghc: {{{ commit 9987c66d7c3a1186acb5a32e92cd6846d71987a5 Author: Thomas Miedema Date: Tue Mar 17 12:08:59 2015 +0100 Fix Windows testsuite driver This got broken in commit 5258566. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 11:31:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 11:31:58 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.52df625a02900fbbddd18ab1521fb6bc@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: merge Priority: normal | Milestone: Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge Comment: Since the first 2 commits were merged to 7.10, I think the other 2 should as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 12:16:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 12:16:52 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.1d1fecc49860e08878d855b9c75d7490@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317, #9159 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch Comment: Ok, I think the code is ready for some review; see Phab:D720. I?d like to land this before adding some of the extra bells and whistles, such as branches code in situations where this is possible. Note that although #10124 and the story about branchless codes made me look at this, the rewrite of code generation for switches stands on its own, as it improves upon the previous situations. In particular, we currently never generate jump tables for case expressions on `Int#` and `Word#`, which is quite a waste (previously reported as #9159 as well), and we were building the if-then-else tree before creating jump tables, thus possibly splitting them in the middle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 14:09:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 14:09:15 -0000 Subject: [GHC] #10165: Win32 broken with GHC 7.10 RC3 Message-ID: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> #10165: Win32 broken with GHC 7.10 RC3 ---------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Using the 32bit Windows build of GHC 7.10 RC3 (ghc-7.10.0.20150316) I can't load the Win32 library. I get the problem: {{{ C:\Neil>ghci GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help Prelude> import System.Win32 Prelude System.Win32> wRITE_DAC : C:\ghc\ghc-7.10.0.20150316\lib\Win32_6dnIMpnCmqmCdDB983aKnr\HSWin 32-2.3.1.0-6dnIMpnCmqmCdDB983aKnr.o: unknown symbol `_SetWindowLongPtrW' ghc.exe: unable to load package `Win32-2.3.1.0' }}} This seems very serious, and breaks all packages that indirectly depend on the Win32 module (which on Windows is most of them). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 14:13:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 14:13:46 -0000 Subject: [GHC] #10165: Win32 broken with GHC 7.10 RC3 In-Reply-To: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> References: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> Message-ID: <066.f0eab239c1d1bf25dd264fd08bf61b81@haskell.org> #10165: Win32 broken with GHC 7.10 RC3 ----------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Comment (by NeilMitchell): I just tried with the 64bit Windows build and that worked fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 14:56:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 14:56:25 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.41e502e94df32ba113f2411e005bad82@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: merge Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 15:58:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 15:58:34 -0000 Subject: [GHC] #8082: Ordering of assembly blocks affects performance In-Reply-To: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> References: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> Message-ID: <063.8078cd995929fc5c9c36f4678f32e15a@haskell.org> #8082: Ordering of assembly blocks affects performance -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I can confirm that this can cause serious wobbles. When working on #10137, I changed the use of `<` to `>=` when generating if-then-else trees, and some numbers went up and some went down, without any guidance as to which one is better: {{{ Min -0.1% -0.0% -3.2% -3.2% 0.0% Max +0.0% 0.0% +4.4% +4.3% +3.3% Geometric Mean -0.0% -0.0% +0.3% +0.3% +0.1% }}} Looks like without dynamic tracing, this problem is not easily solved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 16:07:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 16:07:17 -0000 Subject: [GHC] #10107: Add Functor etc. to Data.Monoid wrappers In-Reply-To: <045.31f9fd043cf1068180e128aefcf56dfc@haskell.org> References: <045.31f9fd043cf1068180e128aefcf56dfc@haskell.org> Message-ID: <060.a622ca079ad1040e70fbe7140b6750e5@haskell.org> #10107: Add Functor etc. to Data.Monoid wrappers -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4880 | Blocking: | Differential Revisions: Phab:D673 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"3f3782df63f7c55382a25687a8e5c7f64202fa0a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3f3782df63f7c55382a25687a8e5c7f64202fa0a" Add more MonadZip instances Summary: Add MonadZip Alt and MonadFix Alt instances Reviewers: ekmett, dfeuer, hvr, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D716 GHC Trac Issues: #10107 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 16:15:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 16:15:49 -0000 Subject: [GHC] #10161: GHC does not relink if a library's code changed In-Reply-To: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> References: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> Message-ID: <057.9414c9784ca4c8f419c0fad903a12adf@haskell.org> #10161: GHC does not relink if a library's code changed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Happens with the RTS too. One answer is, if your library changes, its version number should change (but this isn't very satisfactory!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 16:23:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 16:23:26 -0000 Subject: [GHC] #9963: GHCi panic with --print-libdir flag In-Reply-To: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> References: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> Message-ID: <063.312f98d31d34d235016c52aa60bc4a48@haskell.org> #9963: GHCi panic with --print-libdir flag -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: thomie Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Driver | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | driver/T9963 | Blocking: | Differential Revisions: Phab:D730 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via f92acd8ed223ebbbf62fab930c6c346f5531d431). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 16:24:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 16:24:27 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.b1f31b51979a59081a1ebf2a4859162a@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Done - all merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 16:52:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 16:52:28 -0000 Subject: [GHC] Batch modify: #8550, #10009, #10079, #7788, #10141, #10155 Message-ID: <20150317165228.095423A2FF@ghc.haskell.org> Batch modification to #8550, #10009, #10079, #7788, #10141, #10155 by thoughtpolice: milestone to 7.12.1 Comment: Moving to 7.12.1 milestone. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 17:22:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 17:22:34 -0000 Subject: [GHC] #10138: hpc does not handle absolute paths correctly In-Reply-To: <045.9bdca9682fa3d158f8da50db7ac5cc99@haskell.org> References: <045.9bdca9682fa3d158f8da50db7ac5cc99@haskell.org> Message-ID: <060.0ea8747ad655af3fad5372805ee7fc22@haskell.org> #10138: hpc does not handle absolute paths correctly -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Code Coverage | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: hpc/T10138 Related Tickets: | Blocking: | Differential Revisions: Phab:D703 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"801f4b98fa5198ab7e033949dd84aaae00162993/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="801f4b98fa5198ab7e033949dd84aaae00162993" hpc: use System.FilePath.() instead of (++) Summary: BAD: "." ++ "/" ++ "/absolute/path" == ".//absolute/path" GOOD: "." "/absolute/path" == "/absolute path" Also replace `++ ".ext"` with `<.> "ext"`. Although it doesn't fix any bugs in this instance, it might in some other. As a general rule it's better not to use (++) on FilePaths. Reviewed By: austin, hvr Differential Revision: https://phabricator.haskell.org/D703 GHC Trac Issues: #10138 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 17:23:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 17:23:17 -0000 Subject: [GHC] #10138: hpc does not handle absolute paths correctly In-Reply-To: <045.9bdca9682fa3d158f8da50db7ac5cc99@haskell.org> References: <045.9bdca9682fa3d158f8da50db7ac5cc99@haskell.org> Message-ID: <060.8cf19a9da0526d72bd5ef87fd95be12b@haskell.org> #10138: hpc does not handle absolute paths correctly -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Code Coverage | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: hpc/T10138 Related Tickets: | Blocking: | Differential Revisions: Phab:D703 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 17:55:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 17:55:49 -0000 Subject: [GHC] #10166: GHCi: internal error: stg_ap_p_ret Message-ID: <051.e2963cfb33e7f7ef7fdb12cd79aa6a85@haskell.org> #10166: GHCi: internal error: stg_ap_p_ret -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs import Unsafe.Coerce coerce = Unsafe.Coerce.unsafeCoerce data Nat = Zero | Suc Nat fromNat :: Nat -> Integer fromNat Zero = 0 fromNat (Suc l) = 1 + fromNat l instance Show Nat where show l = show (fromNat l) data Exp = Const Nat | Pred | App Exp Exp eval :: Exp -> a eval (Const n) = coerce n eval e = coerce $ evalP e where evalP Pred Zero = Zero evalP Pred (Suc n) = n evalP e n = evalA e n evalA (App f e) = eval f (eval e) evalA _ = error "eval" -- With type signature, result is 0 (wrong, should be 1) -- Without type signature: internal error: stg_ap_p_ret -- test :: Nat test = eval $ App Pred $ Const $ Suc $ Suc Zero -- main prints 0 should maybe print 1 main :: IO () main = print (coerce test :: Nat) }}} when evaluatiing test at the ghci prompt after loading, I get {{{ : internal error: stg_ap_p_ret (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Process haskell aborted (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 18:24:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 18:24:22 -0000 Subject: [GHC] #9261: -S prints incorrect number of bound tasks In-Reply-To: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> References: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> Message-ID: <059.f8454a3380b15961895b737c30a3dcb9@haskell.org> #9261: -S prints incorrect number of bound tasks -------------------------------------+------------------------------------- Reporter: edsko | Owner: thomie Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => * owner: simonmar => thomie Comment: @edsko: I think the code is correct ''as is''. `taskCount` is not decremented when a worker task is stopped, but only when `freeMyTask` is called, which frees the task bound to the current thread. So `taskCount` is the current number of bound tasks + the total number of worker tasks. I suggest to just add a comment to the definition of `taskCount`: `// currentBoundCount + workerCount`. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 18:46:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 18:46:44 -0000 Subject: [GHC] #9839: RTS options parser silently accepts invalid flags In-Reply-To: <049.1ac180907787acdf75c140998b5b4263@haskell.org> References: <049.1ac180907787acdf75c140998b5b4263@haskell.org> Message-ID: <064.7b8b34a4cd288ef058f4f8164f744ffb@haskell.org> #9839: RTS options parser silently accepts invalid flags -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #4243 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * owner: simonmar => Comment: The file to change is: `rts/RtsFlags.c`. Not difficult. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 19:01:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 19:01:05 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.b7083d423a64d711dcf9790bc9a87c26@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 19:13:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 19:13:53 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.9e0bd2c9fd43bc3e78300a5bbe061548@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 22:06:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 22:06:27 -0000 Subject: [GHC] #10165: Win32 broken with GHC 7.10 RC3 In-Reply-To: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> References: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> Message-ID: <066.eaf302a3a94d795cb9750cbf123c676e@haskell.org> #10165: Win32 broken with GHC 7.10 RC3 ----------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Comment (by m37): Documentation on MSDN for SetWindowLongPtr [https://msdn.microsoft.com/en- us/library/windows/desktop/ms633591%28v=vs.85%29.aspx] indicates that SetWindowLongPtrW only exists on 64-bit. It appears that the win32 library should be fixed to conditionally call SetWindowLongW on 32-bit, and call SetWindowLongPtrW on 64-bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 22:08:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 22:08:36 -0000 Subject: [GHC] #10166: GHCi: internal error: stg_ap_p_ret In-Reply-To: <051.e2963cfb33e7f7ef7fdb12cd79aa6a85@haskell.org> References: <051.e2963cfb33e7f7ef7fdb12cd79aa6a85@haskell.org> Message-ID: <066.aa5326e422dcb8d9e1a8baf05f0b7a39@haskell.org> #10166: GHCi: internal error: stg_ap_p_ret -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => invalid Comment: Letting X be a shortcut for `Const (Suc (Suc Zero))`, your program makes an evaluation step {{{ eval (App Pred X) => coerce $ evalP (App Pred X)` }}} and attempts to print this as a `Nat`, but `evalP (App Pred X)` is a function (evalP takes two arguments), that's an invalid coercion. If you change your `eval` to {{{#!hs eval :: Exp -> a eval (Const n) = coerce n eval Pred = coerce pr eval (App f e) = coerce (eval f (eval e)) pr Zero = Zero pr (Succ n) = n }}} then it works on my machine, but you should use `Any` for such tricks (https://hackage.haskell.org/package/ghc-prim-0.3.1.0/docs/GHC- Prim.html#v:unsafeCoerce35-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 22:24:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 22:24:24 -0000 Subject: [GHC] #10167: Error with dash character Message-ID: <045.7058519873a76f56757172245184b3a3@haskell.org> #10167: Error with dash character -------------------------------------+------------------------------------- Reporter: elvinz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I copy the formula from the webpage http://www.experiglot.com/2006/06/07/how-to-convert-from-an-annual-rate- to-an-effective-periodic-rate-javascript-calculator/ as this formula: yearlyToMonthly rate nbPeriods = (1 + rate)(1 / nbPeriods) ? 1 I get the following error message in ghci which is due the the minus character not being encoded as an hyphen but as an en dash: main.hs:3:60: Not in scope: `*** Exception: : commitBuffer: invalid argu ment (invalid character) Would it be possible to have a more informative error message ? My system is win 7 64 bits, and the locale is fr;French (France). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 17 22:51:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Mar 2015 22:51:44 -0000 Subject: [GHC] #10166: GHCi: internal error: stg_ap_p_ret In-Reply-To: <051.e2963cfb33e7f7ef7fdb12cd79aa6a85@haskell.org> References: <051.e2963cfb33e7f7ef7fdb12cd79aa6a85@haskell.org> Message-ID: <066.57e4960d76d0481ff26741786941f15a@haskell.org> #10166: GHCi: internal error: stg_ap_p_ret -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, there's a reason that `unsafeCoerce` is called "`unsafeCoerce`" :-). Renaming it to `coerce` is arguably misleading, especially since `Data.Coerce` exports a guaranteed-sound function `coerce`! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 00:40:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 00:40:38 -0000 Subject: [GHC] #10165: Win32 broken with GHC 7.10 RC3 In-Reply-To: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> References: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> Message-ID: <066.35642810d4fa4324bf84aeb8e02c9cf1@haskell.org> #10165: Win32 broken with GHC 7.10 RC3 ----------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Comment (by Kludgy): Untested fix here for review: https://github.com/Kludgy/win32/commit/9e52103b8b4a9bfb486e2289257ec61ac682eb89 I will submit this as a PR as soon as I am able to verify that it works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 02:07:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 02:07:19 -0000 Subject: [GHC] #8082: Ordering of assembly blocks affects performance In-Reply-To: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> References: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> Message-ID: <063.77d9c5aae3d63b7926ee61c7bde62d6d@haskell.org> #8082: Ordering of assembly blocks affects performance -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): could that be a branch prediction issue? (plus perhaps a matter of memory locality in the instruction cache?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 06:09:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 06:09:07 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ Message-ID: <048.86721c518b657437564df331356981ea@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1-rc1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- These need only an Applicative constaint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 09:07:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 09:07:11 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.d5b2ffc89adc6e5d9bb06b2d6e700000@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 09:29:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 09:29:56 -0000 Subject: [GHC] #1008: Remove unregisterised way In-Reply-To: <047.5cdc3eb7bc71bfc1aefccc2827fcf08b@haskell.org> References: <047.5cdc3eb7bc71bfc1aefccc2827fcf08b@haskell.org> Message-ID: <062.26b111bafdd8391d70e21d8165fd4a14@haskell.org> #1008: Remove unregisterised way -------------------------------------+--------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: low | Milestone: 6.8.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: | -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"3508b68f1a1e9a7ba4cdea5bac4e557739349da1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3508b68f1a1e9a7ba4cdea5bac4e557739349da1" Remove mention of `-unreg` in error message The `-unreg` flag was removed in commit dade8ab (2007), see #1008. [skip-ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 09:59:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 09:59:32 -0000 Subject: [GHC] #8082: Ordering of assembly blocks affects performance In-Reply-To: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> References: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> Message-ID: <063.4b35fa854bb6dad5bc669ae0bcedd7c9@haskell.org> #8082: Ordering of assembly blocks affects performance -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Yes, quite likely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 10:32:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 10:32:06 -0000 Subject: [GHC] #8123: GHCi warns about -eventlog even though it's sometimes necessary In-Reply-To: <043.6d79c34e9438338948ab4ac93632c1d6@haskell.org> References: <043.6d79c34e9438338948ab4ac93632c1d6@haskell.org> Message-ID: <058.5c8244dc449152c8ba6e247ece59f4cb@haskell.org> #8123: GHCi warns about -eventlog even though it's sometimes necessary -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * status: new => infoneeded Comment: @akio I can't reproduce your bug. Could you please supply some example code where running `ghci` with `-eventlog` ''does'' make a difference. Here's what I've tried: {{{ $ cat Test.hs main = return () $ ghc-7.6.3 -fforce-recomp -eventlog -c Test.hs $ ghc-7.6.3 --interactive Test.o GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) Test.o ... done final link ... done Leaving GHCi. }}} Seems to work fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 11:36:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 11:36:11 -0000 Subject: [GHC] #8315: Improve specialized Hoopl module In-Reply-To: <048.5406a9d3d2f8eb7a85a9feb3e1857868@haskell.org> References: <048.5406a9d3d2f8eb7a85a9feb3e1857868@haskell.org> Message-ID: <063.1993c7dbbd70a51c6fc69cf5d14a5a37@haskell.org> #8315: Improve specialized Hoopl module -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: apankiv Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by apankiv): * owner: => apankiv -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 11:59:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 11:59:57 -0000 Subject: [GHC] #10165: Win32 broken with GHC 7.10 RC3 In-Reply-To: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> References: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> Message-ID: <066.e30b176b678766fb5c94c14f8a4fc806@haskell.org> #10165: Win32 broken with GHC 7.10 RC3 ----------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Changes (by hvr): * priority: normal => highest * milestone: => 7.10.1 Comment: let's consider this a blocker until proven otherwise :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 12:00:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 12:00:41 -0000 Subject: [GHC] #10165: Win32 broken with GHC 7.10 RC3 In-Reply-To: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> References: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> Message-ID: <066.d492c122c54fa6110b0b4153c019c680@haskell.org> #10165: Win32 broken with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc3 (other) | Keywords: Win32 Resolution: | Architecture: x86 Operating System: Windows | Test Case: Type of failure: Runtime crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => Win32 * component: Compiler => libraries (other) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 12:07:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 12:07:40 -0000 Subject: [GHC] #10115: Unable to run cabal haddock --hoogle on GHC 7.10 In-Reply-To: <047.decd164805e4d10458a8e3160e406e34@haskell.org> References: <047.decd164805e4d10458a8e3160e406e34@haskell.org> Message-ID: <062.c6cb9fd3dbbecb952b6f1b3dfe9ffd2a@haskell.org> #10115: Unable to run cabal haddock --hoogle on GHC 7.10 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: This was merged into ghc-7.10 via cb51506b02a2ecf7b5e67a8069e61f4e8375ba67 Also, I can't reproduce this with RC3 anymore, so I'm closing this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 13:41:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 13:41:43 -0000 Subject: [GHC] #9921: Building Haddocks with Hoogle output results in an error In-Reply-To: <047.5612adaf4961bd48041d34575c43a0f4@haskell.org> References: <047.5612adaf4961bd48041d34575c43a0f4@haskell.org> Message-ID: <062.f2006d7293ca00b1fdeb9b6e8a7c5cf9@haskell.org> #9921: Building Haddocks with Hoogle output results in an error -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): Why was this moved to the 7.12 milestone? I would certainly consider breaking Hoogle generation a blocker for the release: it's a major regression in a commonly used feature. I'm trying to confirm the fix for this now, but I'd be more comfortable if this was moved back to the 7.10 milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 13:58:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 13:58:40 -0000 Subject: [GHC] #9921: Building Haddocks with Hoogle output results in an error In-Reply-To: <047.5612adaf4961bd48041d34575c43a0f4@haskell.org> References: <047.5612adaf4961bd48041d34575c43a0f4@haskell.org> Message-ID: <062.ca8c913d97524990ba7fff5f379757a1@haskell.org> #9921: Building Haddocks with Hoogle output results in an error -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * status: new => closed * resolution: => fixed Comment: Regardless of milestone, I've confirmed that the latest Cabal library fixes this: https://github.com/haskell/cabal/pull/2439#issuecomment-82985223 Closing the ticket, though Neil may still have problems with the Hoogle generated output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 16:02:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 16:02:17 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.b9ae85844a09774434c205224441af51@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by strake888): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 23:04:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 23:04:48 -0000 Subject: [GHC] #10169: bracket not running the final action on termination through SIGTERM Message-ID: <049.187549585367c5b196e79dc7c9aece4e@haskell.org> #10169: bracket not running the final action on termination through SIGTERM -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Operating System: Linux Keywords: | Type of failure: Incorrect result Architecture: x86 | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- If a program compiled with GHC receives a SIGTERM signal, while in a bracket, the final action of the bracket isn't executed. This can be tested with this program: {{{#!hs import Control.Exception import Control.Concurrent main = bracket (return "ending") (\x -> putStrLn x) (\_ -> threadDelay 10000000000) }}} When running this and interrupting with ctrl-c (thus SIGINT) it prints "ending", like expected. When interrupting it with {{{killall -TERM test}}} (assuming the program was named test) "ending" isn't printed and the program terminates immediately. It prints a system specific message though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 18 23:43:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Mar 2015 23:43:24 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.09436943de6ddcd4ca51d075b2d368a4@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Akio, good work. But I would be reluctant to zap demand info: * Occurrence info is syntactic, and changes often, so needs to be zapped * Demand info is (supposed to be) semantic, and so should not change, except that the demand might get stronger; it is a static analysis after all. So my diagnosis is that the demand analyser is wrong. Consider -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 00:39:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 00:39:11 -0000 Subject: [GHC] #10165: Win32 broken with GHC 7.10 RC3 In-Reply-To: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> References: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> Message-ID: <066.e3aa67fb974ba84646b28925bc6d802c@haskell.org> #10165: Win32 broken with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc3 (other) | Keywords: Win32 Resolution: | Architecture: x86 Operating System: Windows | Test Case: Type of failure: Runtime crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Kludgy): PR submitted for review: https://github.com/haskell/win32/pull/34 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 00:51:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 00:51:23 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools Message-ID: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (LLVM) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since it has become more widely know that the LLVM developers often make breaking changes to the IR language between releases, some Linu distributions (eg Debain and hence Ubuntu) have started doing multi- version LLVM installs. For instance on Debian, the llvm-3.6 programs are installed in `/usr/lib/llvm-3.6/bin` as `llc` and `opt`. I propose that the `configure.ac` and `aclocal.m4` configuration goop be modified to look for `llc` and `opt` in these versioned `/usr/lib/llvm-X.Y` locations. I'm also willing to do the hard yards on implementing this if people think its a good idea. This can be seen as a step along the way to more stringent LLVM versioning requirements. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 00:56:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 00:56:39 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.6ee6f1eb32756ea07ccb23af8c0f57ad@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): This should already work. If it doesn't, than that's indeed a bug. See commit 1dfab7a8ace5f09f00f8fb695932b4324e88b822 {{{ Author: Thomas Miedema Date: Mon Mar 2 11:09:33 2015 -0600 Fix detection of llvm-x.x Summary: Four bug fixes and a little refactoring. * `find -perm \mode` should be `find -perm /mode` (#9697) * `find -regex '$3' should be `find -regex "$3"` (#7661) From `man sh` on my system (Ubuntu 14.04): "Enclosing characters in single quotes preserves the literal meaning of all the characters ..." * LlcCmd and OptCmd should be passed to ghc, using `-pgmlo` and `-pgmlc`, for detection of #9439. * -pgmlo and -pgmlc were undocumented because of an xml tag misplacement. Test Plan: The aclocal.m4 macro has seen about 10 iterations since its inception. Without a testsuite, I can't guarantee this version is bug free either. It's all pretty frustrating. Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D683 GHC Trac Issues: #9697, #7661, #9439 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 01:07:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 01:07:35 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.2f8b0a583762608da23bc14e3c22d813@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): @thomie It doesn't work now, because on my machine it picks `/usr/bin/llc` (which is actually a symlink to `/usr/lib/llvm-3.5/bin/llc`) before it picks `/usr/lib/llvm-3.6/bin/llc`. I can't remove llvm-3.5 because I have other tools that rely on it. If people think its a good idea, I would make the configure script check for a specific version of the llvm tools (currently 3.6 because thats all that seems to work currently). With this versioned check, when we move to another version of LLVM there should be one single change to configure.ac to make it check for the new version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 01:30:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 01:30:24 -0000 Subject: [GHC] #10171: runghc has problem when the argument list is too big Message-ID: <045.96454332beb6fa9e279ce43759cb41f3@haskell.org> #10171: runghc has problem when the argument list is too big -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: POSIX Architecture: | Type of failure: Runtime crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The way `runghc` works is by calling `ghc` with some extra arguments. These extra arguments cause the `argv` passed to `ghc` to be larger than the original one. This can cause the size of `argv` to exceed the maximum allowed. This might seem like a minor issue, but it can confuse several unix tools that rely on exact calculations on the size of `argv`, such as `xargs` or `find` with the `-exec` option. To demonstrate the problem, consider the following the program (call it `print_size.hs`): {{{#!hs import System.Environment import System.Posix main = getArgs >>= mapM_ printSize where printSize file = do st <- getSymbolicLinkStatus file putStrLn $ show (fileSize st) ++ " " ++ file }}} The program interpreters its `argv` as a list of files and prints their sizes. Now suppose that you want to run the program without compiling it (i.e. by interpreting it) on a specific set files, as returned by `find`. For example, consider something like that: {{{ find / -exec runhaskell print_size.hs {} + }}} If you run this, you will get the following error (multiple times): {{{ runghc: /usr/bin/ghc: rawSystem: runInteractiveProcess: exec: resource exhausted (Argument list too long) }}} The problem here is that the `-exec` option of `find`, when used with the `+` switch, works as follows: it starts collecting the list of found files and just before the list exceeds the maximum allowed size for `argv` it runs the specified program on that list (it works this way in order to minimize the number of times the program is ran). Of course this is problematic because `runghc` will then increase the size of `argv` and because of that the call to `ghc` might fail. The same thing happens if you try to run the following as well: {{{ find / -print0 | xargs -0 runhaskell print_size.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 01:36:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 01:36:51 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.6cbc73fb5fd96a144d06c2f0e8ef4120@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Sounds good, to me at least. Hopefully it allows you to delete that `FIND_LLVM` macro. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 01:52:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 01:52:49 -0000 Subject: [GHC] #10171: runghc has problem when the argument list is too big In-Reply-To: <045.96454332beb6fa9e279ce43759cb41f3@haskell.org> References: <045.96454332beb6fa9e279ce43759cb41f3@haskell.org> Message-ID: <060.9534e7cf8c656274efc4dc179e2b0e0d@haskell.org> #10171: runghc has problem when the argument list is too big -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: POSIX | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by redneb): Currently, when you run `runhaskell script.hs arg1 arg2`, `ghc` is called with the following arguments: {{{ -ignore-dot-ghci -x hs -e ':set prog "script.hs"' -e ':main ["arg1", "arg2"]' }}} Note the the `["arg1", "arg2"]` part is generated by calling `show` on the list of original arguments. This is very inefficient. One solution is to introduce a new flag for `ghc` that would directly interpret the specified file. The new flag must have a short name so that the length of `"ghc"` plus the length of the flag name plus 1 (for the null character) is less than the length of `"runhaskell"`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 02:13:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 02:13:31 -0000 Subject: [GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot In-Reply-To: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> References: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> Message-ID: <057.d65e5e562f6b5aaab5ad44e5c7bc217b@haskell.org> #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #5554 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * related: => #5554 Comment: I have a fix for this. Waiting on the outcome of https://github.com/haskell/filepath/issues/43 first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 02:43:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 02:43:35 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.1c9c877e172bc12453c766ff3ce5f4b0@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): On my Debian system there is also `/usr/bin/llc-3.x` which is a symlink to `/usr/lib/llvm-3.x/bin/llc`. If GHC requires LLVM 3.6, for instance, wouldn't it be best to look for `llc-3.6` in the `$PATH`, rather than specifically `/usr/lib/llvm-3.6/bin/llc`? Then it would also work if the user installed `llc-3.6` other than through their package manager (e.g., in `~/bin`). Maybe this is what you were suggesting in comment:2, not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 02:58:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 02:58:21 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.efc7d8a1d6d26ad62bf547056685c4ee@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): @rwbarton Yes, it should look for a versioned `/usr/lib/llc-X.Y` but also accept `/usr/lib/llvm-3.6/bin/llc`. More importantly configure should fail if whatever version of `llc` it finds isn't the currently blessed version. @thomie Unfortunately, I think that `FIND_LLVM` macro will need to grow, not disappear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 03:17:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 03:17:10 -0000 Subject: [GHC] #10171: runghc has problem when the argument list is too big In-Reply-To: <045.96454332beb6fa9e279ce43759cb41f3@haskell.org> References: <045.96454332beb6fa9e279ce43759cb41f3@haskell.org> Message-ID: <060.35e8ed57956b291de860f5aba34ea812@haskell.org> #10171: runghc has problem when the argument list is too big -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: POSIX | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7980 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #7980 Comment: Usually there is a limit on the size of an individual argument as well as a (much larger) limit on the total size of all the arguments. So the `':main ["arg1", "arg2"]'` argument can end up exceeding the former limit even when the original command was nowhere near either limit. See #7980. This may be what is going wrong for you too (despite the wording of the error message "Argument ''list'' too long"; note that it is the same in the linked ticket). The way to fix this would be to preserve the original argument list as a suffix of the argument list to ghc, with something like {{{ -ignore-dot-ghci -x hs -e ':set prog "script.hs"' -e ':main' script.hs --with-remaining-arguments arg1 arg2 }}} That still leaves the original issue, though. If `xargs` really leaves ''no'' extra room in the argument list size, I would consider that more than a bit crazy. Recall also that `runhaskell` is a symbolic link to `runghc` and the user could invoke the latter directly, which gives you 4 fewer characters to work with. For that matter, the user could invoke `runghc` through another symlink named `r`, and then you are really stuck! For this reason I think playing games with the lengths of GHC's options is a bit misguided. It may be the simplest solution to both issues to have `runghc` simply invoke the GHC API directly (ideally reusing the code of `ghci`) rather than launching a separate `ghc` process. Now that we have dynamic libraries, the extra binary size is no concern right? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 03:18:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 03:18:20 -0000 Subject: [GHC] #7980: runghc dies silently when given large numbers of arguments. Compiled code does not. In-Reply-To: <047.c173581a8082e621038026d031d5d041@haskell.org> References: <047.c173581a8082e621038026d031d5d041@haskell.org> Message-ID: <062.545a8899d8cd03742dcb974b131c27f2@haskell.org> #7980: runghc dies silently when given large numbers of arguments. Compiled code does not. -------------------------------------+------------------------------------- Reporter: totherme | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10171 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #10171 Comment: (Someone did open a new ticket: #10171.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 03:27:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 03:27:17 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.fae65d5029899deaf6bc7fccc02727a0@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Nope, it turns out that on Debian, the `/usr/bin/llc-3.6` symlink is managed by the `llvm-3.6` package. Its the `/usr/bin/llc` symlink that is managed by the Debian `alternatives` system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 03:43:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 03:43:06 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.394979cdbaaf5bf37add8736ec5b48ba@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): > More importantly configure should fail if whatever version of llc it finds isn't the currently blessed version. Right. > Yes, it should look for a versioned `/usr/lib/llc-X.Y` but also accept `/usr/lib/llvm-3.6/bin/llc` Let me rephrase what I meant. Hard-coding knowledge of the directory `/usr/lib/llvm-3.6/bin` into ghc's autoconf is wrong because (in my estimation) the fact that `llc-3.6` is a symlink to `/usr/lib/llvm-3.6/bin/llc` is an implementation detail of the Debian `llvm-3.6` package and the executable may be (and is) located elsewhere on other distributions. The public interface of `llvm-3.6` (on Debian and hopefully on other distributions) is that it provides `llc-3.6` on the standard `$PATH`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 03:56:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 03:56:50 -0000 Subject: [GHC] #10169: bracket not running the final action on termination through SIGTERM In-Reply-To: <049.187549585367c5b196e79dc7c9aece4e@haskell.org> References: <049.187549585367c5b196e79dc7c9aece4e@haskell.org> Message-ID: <064.490a0c9dfc14d27a38ee9908ef10aedc@haskell.org> #10169: bracket not running the final action on termination through SIGTERM -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): The GHC runtime doesn't install any signal handler for SIGTERM by default, so the program just exits immediately. See ticket:6113#comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 04:01:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 04:01:00 -0000 Subject: [GHC] #10166: GHCi: internal error: stg_ap_p_ret In-Reply-To: <051.e2963cfb33e7f7ef7fdb12cd79aa6a85@haskell.org> References: <051.e2963cfb33e7f7ef7fdb12cd79aa6a85@haskell.org> Message-ID: <066.c3584acea8c2ae801f903dd88a389329@haskell.org> #10166: GHCi: internal error: stg_ap_p_ret -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): (And this is a task that [http://en.wikibooks.org/wiki/Haskell/GADT GADTs] are well-suited for, in place of `unsafeCoerce`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 04:41:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 04:41:38 -0000 Subject: [GHC] #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL In-Reply-To: <048.55a9661044b934d281580d4eba633a8a@haskell.org> References: <048.55a9661044b934d281580d4eba633a8a@haskell.org> Message-ID: <063.13598b2b8d3857a828c072965e23caf0@haskell.org> #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: :sprint Operating System: Unknown/Multiple | thunk evaluation non-strictness Type of failure: Incorrect result | laziness runtime ghci repl at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bitemyapp: Old description: > Wanted to use :sprint to help learners visualise thunk evaluation > behavior in their data. Ran into some behaviors that a few people I > checked with didn't have a good explanation for. I couldn't find anything > in the user guide to explain this. I don't think it technically violates > Haskell Report requirements, but it makes :sprint considerably less > useful if you're teaching somebody non-strictness. > > Examples with code in the REPL: > > {{{ > Prelude> let x = [1, 2, 3 :: Integer] > Prelude> :sprint x > x = [1,2,3] > -- errr, what? > > Prelude> let x = Just (1 :: Integer) > Prelude> :sprint x > x = Just 1 > > Prelude> let just = Just > Prelude> let x = just (1 :: Integer) > Prelude> :sprint x > x = _ > > Prelude> let x = Just (undefined :: Integer) > Prelude> :sprint x > x = Just _ > > Prelude> let x = just (undefined :: Integer) > Prelude> :sprint x > x = _ > > Prelude> let x = [1, 2, 3 :: Integer] > Prelude> let y = x > Prelude> :sprint y > y = [1,2,3] > > Prelude> let x = 1 : 2 : (3 :: Integer) : [] > Prelude> :sprint x > x = [1,2,3] > Prelude> let x = [1] ++ [2] ++ [(3 :: Integer)] > Prelude> :sprint x > x = _ > > Prelude> let y = (:) > Prelude> let x = 1 `y` (2 `y` ((3 :: Integer) `y` [])) > Prelude> :sprint x > x = _ > Prelude> x > [1,2,3] > Prelude> :sprint x > x = [1,2,3] > }}} > > So the behavior here seems to be: > > Constructors used directly in the construction of data and are not passed > functions (including polymorphic vals awaiting concrete > instances)/bottoms are immediately evaluated > > Example, but with loading data from a file: > > Contents of the file: > > {{{ > x :: Num a => [a] > x = [1, 2, 3] > }}} > > GHCi session: > > {{{ > Prelude> :t x > x :: Num a => [a] > > Prelude> :sprint x > x = _ > > Prelude> x > [1,2,3] > > Prelude> :sprint x > x = _ > }}} > > Then when x is loaded from a file, but has a different type: > > {{{ > Prelude> :t x > x :: [Integer] > Prelude> :sprint x > x = _ > Prelude> head x > 1 > Prelude> :sprint x > x = [1,2,3] > }}} > > Now, this is a bit confusing. Earlier I was able to get :sprint to return > [1, _, _] when I evaluated head x, but a couple hours later when I went > to write this ticket, I couldn't reproduce that behavior. > > Is there documentation that explains: > > 1. Why data is shown as having been evaluated at time of declaration > (seemingly) by :sprint when it's defined in the GHCi > > 2. Why declaring code in GHCi and loading it from a file behaves > differently with :sprint (I considered let expression in the implicit > GHCi do-block...couldn't find anything to explain this) > > 3. Why evaluating 'head x' forces the other values as well > > Are any of these behaviors a bug? If not, are they documented anywhere? > Is the "eager" treatment of constructors in GHCi a performance thing? > That seems strange given I didn't have -fobject-code turned on. > > :sprint not demonstrating semantics that match what I expect from a non- > strict language hinders its utility as a teaching tool and means the only > robust option for learners that I can find is testing evaluation with > bottom values. > > {{{ > -- So that you know i picked "7.8.4" as the version consciously > > [callen at atlantis ~/Work/fpbook]$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.8.4 > > [callen at atlantis ~/Work/fpbook]$ ghci --version > The Glorious Glasgow Haskell Compilation System, version 7.8.4 > }}} New description: Wanted to use :sprint to help learners visualise thunk evaluation behavior in their data. Ran into some behaviors that a few people I checked with didn't have a good explanation for. I couldn't find anything in the user guide to explain this. I don't think it technically violates Haskell Report requirements, but it makes :sprint considerably less useful if you're teaching somebody non-strictness. Examples with code in the REPL: {{{ Prelude> let x = [1, 2, 3 :: Integer] Prelude> :sprint x x = [1,2,3] -- errr, what? Prelude> let x = Just (1 :: Integer) Prelude> :sprint x x = Just 1 Prelude> let just = Just Prelude> let x = just (1 :: Integer) Prelude> :sprint x x = _ Prelude> let x = Just (undefined :: Integer) Prelude> :sprint x x = Just _ Prelude> let x = just (undefined :: Integer) Prelude> :sprint x x = _ Prelude> let x = [1, 2, 3 :: Integer] Prelude> let y = x Prelude> :sprint y y = [1,2,3] Prelude> let x = 1 : 2 : (3 :: Integer) : [] Prelude> :sprint x x = [1,2,3] Prelude> let x = [1] ++ [2] ++ [(3 :: Integer)] Prelude> :sprint x x = _ Prelude> let y = (:) Prelude> let x = 1 `y` (2 `y` ((3 :: Integer) `y` [])) Prelude> :sprint x x = _ Prelude> x [1,2,3] Prelude> :sprint x x = [1,2,3] }}} So the behavior here seems to be: Constructors used directly in the construction of data and are not passed functions (including polymorphic vals awaiting concrete instances)/bottoms are immediately evaluated Example, but with loading data from a file: Contents of the file: {{{ x :: Num a => [a] x = [1, 2, 3] }}} GHCi session: {{{ Prelude> :t x x :: Num a => [a] Prelude> :sprint x x = _ Prelude> x [1,2,3] Prelude> :sprint x x = _ -- ^^ this is expected }}} Then when x is loaded from a file, but has a different type: {{{ Prelude> :t x x :: [Integer] Prelude> :sprint x x = _ Prelude> head x 1 Prelude> :sprint x x = [1,2,3] -- ^^ this is not }}} Now, this is a bit confusing. Earlier I was able to get :sprint to return [1, _, _] when I evaluated head x, but a couple hours later when I went to write this ticket, I couldn't reproduce that behavior. Is there documentation that explains: 1. Why data is shown as having been evaluated at time of declaration (seemingly) by :sprint when it's defined in the GHCi 2. Why declaring code in GHCi and loading it from a file behaves differently with :sprint (I considered let expression in the implicit GHCi do-block...couldn't find anything to explain this) 3. Why evaluating 'head x' forces the other values as well Are any of these behaviors a bug? If not, are they documented anywhere? Is the "eager" treatment of constructors in GHCi a performance thing? That seems strange given I didn't have -fobject-code turned on. :sprint not demonstrating semantics that match what I expect from a non- strict language hinders its utility as a teaching tool and means the only robust option for learners that I can find is testing evaluation with bottom values. {{{ -- So that you know i picked "7.8.4" as the version consciously [callen at atlantis ~/Work/fpbook]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 [callen at atlantis ~/Work/fpbook]$ ghci --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 05:13:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 05:13:22 -0000 Subject: [GHC] #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL In-Reply-To: <048.55a9661044b934d281580d4eba633a8a@haskell.org> References: <048.55a9661044b934d281580d4eba633a8a@haskell.org> Message-ID: <063.15cbdfcb0e09bfb1b59fd53f3bac0fb5@haskell.org> #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: :sprint Operating System: Unknown/Multiple | thunk evaluation non-strictness Type of failure: Incorrect result | laziness runtime ghci repl at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Well to start with, none of this is really "behavior of `:sprint`": it's the behavior of ghci when interpreting expressions, and the details of this behavior are exposed by `:sprint`. Specifically, constructors are always fully applied in Core, so when ghci encounters a constructor application, it can (emit code to) directly produce a heap object representing an evaluated constructor, rather than producing whatever sort of heap object represents the application of an unknown function and leaving it to be reduced to WHNF later. I imagine that similar comments would apply to the case of integer literals at type `Integer`, where ghci should just build the required `Integer` literal directly rather than building a thunk for an application of `fromInteger` (whose argument would be exactly the necessary `Integer` literal anyways). Yes, this is done for performance reasons, but it's a more basic sort of thing than GHC's optimization passes. It would be quite poor for ghci not to work this way. I think this answers your question 1. As for 2 and 3, I don't know about the details of loading code from a file. It could be that in your example `x` is initially bound in ghci to something along the lines of `loadSymbol "Main.x"`, though I am just speculating based on your experiments. You might consider using an enumeration `let x = [1..3 :: Integer]`, which would behave a bit more like you expect, though forcing elements of that list will also cause earlier elements to be evaluated. I'm sure you can cook up a workaround for that if necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 05:16:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 05:16:36 -0000 Subject: [GHC] #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL In-Reply-To: <048.55a9661044b934d281580d4eba633a8a@haskell.org> References: <048.55a9661044b934d281580d4eba633a8a@haskell.org> Message-ID: <063.18d354d650486b0dfb2d69d1ef194a84@haskell.org> #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: :sprint Operating System: Unknown/Multiple | thunk evaluation non-strictness Type of failure: Incorrect result | laziness runtime ghci repl at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bitemyapp): Yeah Carter had pointed me to the enumFromTo example which has behavior more like what I would expect. The optimization being performed makes sense, the inconsistencies do not. This would appear to mean I am limited to _|_ for reliably demonstrating what values as a general class will or won't get evaluated. Is there something more visual that wouldn't surprise beginners too much? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 06:31:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 06:31:09 -0000 Subject: [GHC] #10145: :info (->) should list its fixity In-Reply-To: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> References: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> Message-ID: <060.01f2446c72f83cc09386837c2fe9dd31@haskell.org> #10145: :info (->) should list its fixity -------------------------------------+------------------------------------- Reporter: oerjan | Owner: phadej Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D741 -------------------------------------+------------------------------------- Changes (by phadej): * owner: => phadej * differential: => Phab:D741 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 08:53:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 08:53:15 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.8d1f45ad92a98c55d011894072d2e71e@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): > I think that FIND_LLVM macro will need to grow, not disappear. In `configure.ac`, can't you just replace: {{{ FIND_LLVM_PROG([LLC], [llc], [llc]) }}} With: {{{ FP_ARG_WITH_PATH_GNU_PROG_OPTIONAL_NOTARGET([LLC], [llc], [llc-3.6]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 09:04:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 09:04:34 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.483f88179c16a7f15cbb77ef1ee00bb2@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I thought the plan was to ship llvm with ghc; wouldn?t that make this obsolete? (Distro packagers can still explicitly tell ghc to use a system installed llvm of the right version using --with-llc etc.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 09:09:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 09:09:42 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.496615af30e377b85ebc0531b69315b1@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): We need llvm 3.6 now, for running the full testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 10:29:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 10:29:42 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.7b3ac4845a520199d1f77644732e248a@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lukyanov): With my patch {{{ghci -e}}} will simply behave like {{{ghc -e}}}. Example: {{{ $ ./ghc-stage2 --interactive -e "2^10" 1024 $ ./ghc-stage2 -e "2^10" --interactive 1024 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 10:43:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 10:43:27 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.549d85277d277f84f89e41eb3bc222be@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): @lukyanov: could you add a test (sometimes more work than making the code change itself), and submit a code review to [wiki:Phabricator]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 12:02:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 12:02:31 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.32a7232bed73936757828ff384b3e782@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: lukyanov Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lukyanov): * owner: => lukyanov -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 12:42:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 12:42:40 -0000 Subject: [GHC] #10169: bracket not running the final action on termination through SIGTERM In-Reply-To: <049.187549585367c5b196e79dc7c9aece4e@haskell.org> References: <049.187549585367c5b196e79dc7c9aece4e@haskell.org> Message-ID: <064.13c504d2c3b7fe6045055e35358439d5@haskell.org> #10169: bracket not running the final action on termination through SIGTERM -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: 6113 | -------------------------------------+------------------------------------- Changes (by Kritzefitz): * related: => 6113 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 12:42:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 12:42:53 -0000 Subject: [GHC] #10169: bracket not running the final action on termination through SIGTERM In-Reply-To: <049.187549585367c5b196e79dc7c9aece4e@haskell.org> References: <049.187549585367c5b196e79dc7c9aece4e@haskell.org> Message-ID: <064.1c10b092d5abf970bd37b47089606297@haskell.org> #10169: bracket not running the final action on termination through SIGTERM -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #6113 | -------------------------------------+------------------------------------- Changes (by Kritzefitz): * related: 6113 => #6113 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 15:14:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 15:14:07 -0000 Subject: [GHC] #9285: IO manager startup procedure somewhat odd In-Reply-To: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> References: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> Message-ID: <059.66635cb267f5062b5264c5ab37179adf@haskell.org> #9285: IO manager startup procedure somewhat odd -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: task | Status: patch Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 16:43:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 16:43:26 -0000 Subject: [GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 In-Reply-To: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> References: <046.77f53bab4b42e7b7f0531b045d80ca9c@haskell.org> Message-ID: <061.133dcda108d474b9e2f5262b6650d34f@haskell.org> #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * milestone: => 7.10.1 Comment: Merged via a86fe8a4602e8e57f3aff3f2bc78055a8fa8fe2e & 072cc766016bf4a09a477f98bb16cf55b253c4f6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 16:53:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 16:53:08 -0000 Subject: [GHC] #9956: Command line flag deprecated warning could be annoying for -Werror users In-Reply-To: <045.317bce8cdeb509002f292d6fe74865f2@haskell.org> References: <045.317bce8cdeb509002f292d6fe74865f2@haskell.org> Message-ID: <060.95f02f8120a331fa9163ae0041db9ef5@haskell.org> #9956: Command line flag deprecated warning could be annoying for -Werror users -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D742 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D742 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 17:50:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 17:50:53 -0000 Subject: [GHC] #4436: Render multi-line strings more prettily in Template Haskell In-Reply-To: <046.7f834be089042d5f0b151d5e002afa18@haskell.org> References: <046.7f834be089042d5f0b151d5e002afa18@haskell.org> Message-ID: <061.e772e6f0092bfec4a2a63cbdd83ed047@haskell.org> #4436: Render multi-line strings more prettily in Template Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T4436 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): For later reference, the commit ids of the above 3 patches are: 98bef4db89b57b01c8f557a027dbeb8ae72407c9 4041be6185f6df8065b84ef10bb664715ca7745d f63a3ead88bc37f2105dcd1def902aef5a3d5944 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 19:21:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 19:21:25 -0000 Subject: [GHC] #9392: "\n" is displayed weirdly in error messages In-Reply-To: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> References: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> Message-ID: <066.1e75e404faef571c89434c1f84b14363@haskell.org> #9392: "\n" is displayed weirdly in error messages -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9681 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => * type: bug => feature request Comment: @Artyom.Kazak: what exactly do you find weird about the current error message? The printing over multiple lines, or just the extra slashes that are added. Perhaps the following would be an improvement: {{{ In the expression: "a\n b" + () }}} Replying to [comment:4 rwbarton]: > The formatting is intentional, see #4436. It would be nice to use the original syntax, though (and set the "original syntax" of a quasiquoter to use the multiline thing). To show the exception from #4436, the following code path is used: `TcSplice.runMeta -> Outputable.ppr -> (instance Outputable HsLit) -> Outputable.pprHsString -> GHC.Show.showMultiLineString` I don't see an easy way to make the change you propose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 19:23:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 19:23:55 -0000 Subject: [GHC] #9956: Command line flag deprecated warning could be annoying for -Werror users In-Reply-To: <045.317bce8cdeb509002f292d6fe74865f2@haskell.org> References: <045.317bce8cdeb509002f292d6fe74865f2@haskell.org> Message-ID: <060.98ddf4f842c83a9cb2fadb098d017d9d@haskell.org> #9956: Command line flag deprecated warning could be annoying for -Werror users -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D742 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged Phab:D742 to `ghc-7.10` via fb326dba5141f8636cb0c0eb0639b8d0c0caa931. Note this is only being committed to the `ghc-7.10` branch; this warning will remain in `HEAD`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 19:33:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 19:33:27 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.d48840987634415cd72581932f03c6ed@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: roldugin Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => roldugin Comment: roldugin: assigning to you, since you were working on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 19:41:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 19:41:14 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.b6d3d307efc9ff820b6bf162b29b0eb9@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: simonmar => * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 20:04:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 20:04:23 -0000 Subject: [GHC] #9609: GHCi gives overly specific error message for unknown constructor In-Reply-To: <045.9950188f6ab93cc71f8af2cda0ae9fed@haskell.org> References: <045.9950188f6ab93cc71f8af2cda0ae9fed@haskell.org> Message-ID: <060.0884a5e58ec02ac265ae9bf98132a27e@haskell.org> #9609: GHCi gives overly specific error message for unknown constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9881 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9881 * milestone: => 7.10.1 Comment: Fixed in 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 20:07:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 20:07:48 -0000 Subject: [GHC] #9572: nofib target for just building should be part of validate In-Reply-To: <045.5fcdc416d003e87a697cbb6b21514f65@haskell.org> References: <045.5fcdc416d003e87a697cbb6b21514f65@haskell.org> Message-ID: <060.771cfa6636ecdc5b6b7331166dedd3cb@haskell.org> #9572: nofib target for just building should be part of validate -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.8.2 suite | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 20:21:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 20:21:33 -0000 Subject: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows. In-Reply-To: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> References: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> Message-ID: <062.22137536889b41758e5a0ede28493420@haskell.org> #7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Replying to [comment:12 gintas]: > No, I am sure I was using hsc2hs from Haskell Platform 2014.2.0.0. I just retested, it works perfectly fine. edwinhere: please reopen again if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 21:15:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 21:15:44 -0000 Subject: [GHC] #9964: GHC crash with NOINLINE and weird IO stuff In-Reply-To: <045.9a8dda45bf1bf3aa22c69d27e354c51f@haskell.org> References: <045.9a8dda45bf1bf3aa22c69d27e354c51f@haskell.org> Message-ID: <060.8cff8993bbb1ff0ef69676a9f0e22f89@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | codeGen/should_compile/T9964 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mietek): I wasn?t able to check this with the 7.10 release candidates yet, as the available bindists don?t support RHEL 6. I haven?t tried to compile 7.10 for RHEL 6 from source yet. When trying to bootstrap ''cabal-install'' 1.22.0.0 with 32-bit [https://downloads.haskell.org/~ghc/7.8.4/ghc-7.8.4-i386-unknown-linux- centos65.tar.xz GHC 7.8.4], there?s another failure: {{{ ... Configuring Cabal-1.22.0.0... Building Cabal-1.22.0.0... Preprocessing library Cabal-1.22.0.0... [ 1 of 80] Compiling Paths_Cabal ( dist/build/autogen/Paths_Cabal.hs, dist/build/Paths_Cabal.o ) [ 2 of 80] Compiling Distribution.TestSuite ( Distribution/TestSuite.hs, dist/build/Distribution/TestSuite.o ) [ 3 of 80] Compiling Distribution.Simple.PreProcess.Unlit ( Distribution/Simple/PreProcess/Unlit.hs, dist/build/Distribution/Simple/PreProcess/Unlit.o ) [ 4 of 80] Compiling Distribution.GetOpt ( Distribution/GetOpt.hs, dist/build/Distribution/GetOpt.o ) [ 5 of 80] Compiling Distribution.PackageDescription.Utils ( Distribution/PackageDescription/Utils.hs, dist/build/Distribution/PackageDescription/Utils.o ) [ 6 of 80] Compiling Distribution.Simple.CCompiler ( Distribution/Simple/CCompiler.hs, dist/build/Distribution/Simple/CCompiler.o ) [ 7 of 80] Compiling Distribution.Compat.ReadP ( Distribution/Compat/ReadP.hs, dist/build/Distribution/Compat/ReadP.o ) [ 8 of 80] Compiling Distribution.Text ( Distribution/Text.hs, dist/build/Distribution/Text.o ) [ 9 of 80] Compiling Distribution.Version ( Distribution/Version.hs, dist/build/Distribution/Version.o ) [10 of 80] Compiling Language.Haskell.Extension ( Language/Haskell/Extension.hs, dist/build/Language/Haskell/Extension.o ) [11 of 80] Compiling Distribution.Compiler ( Distribution/Compiler.hs, dist/build/Distribution/Compiler.o ) [12 of 80] Compiling Distribution.Simple.Compiler ( Distribution/Simple/Compiler.hs, dist/build/Distribution/Simple/Compiler.o ) [13 of 80] Compiling Distribution.Simple.GHC.ImplInfo ( Distribution/Simple/GHC/ImplInfo.hs, dist/build/Distribution/Simple/GHC/ImplInfo.o ) Distribution/Simple/GHC/ImplInfo.hs:17:1: Warning: The import of ?CompilerId? from module ?Distribution.Simple.Compiler? is redundant [14 of 80] Compiling Distribution.License ( Distribution/License.hs, dist/build/Distribution/License.o ) [15 of 80] Compiling Distribution.ModuleName ( Distribution/ModuleName.hs, dist/build/Distribution/ModuleName.o ) [16 of 80] Compiling Distribution.Package ( Distribution/Package.hs, dist/build/Distribution/Package.o ) [17 of 80] Compiling Distribution.System ( Distribution/System.hs, dist/build/Distribution/System.o ) [18 of 80] Compiling Distribution.PackageDescription ( Distribution/PackageDescription.hs, dist/build/Distribution/PackageDescription.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for i386-unknown-linux): (Array.!): undefined array element }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 21:21:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 21:21:02 -0000 Subject: [GHC] #10165: Win32 broken with GHC 7.10 RC3 In-Reply-To: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> References: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> Message-ID: <066.6679c681aacf099bb19e9bd4bace17ec@haskell.org> #10165: Win32 broken with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc3 (other) | Keywords: Win32 Resolution: | Architecture: x86 Operating System: Windows | Test Case: Type of failure: Runtime crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"2ff68c3589af86811f65991c71f33282e0e50778/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2ff68c3589af86811f65991c71f33282e0e50778" libraries: update win32 submodule This update fixes #10165. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 21:22:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 21:22:00 -0000 Subject: [GHC] #10165: Win32 broken with GHC 7.10 RC3 In-Reply-To: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> References: <051.907e70d00729ce9eb799eefe1f30c790@haskell.org> Message-ID: <066.3de2cbaf1d0aa5a0cebc3cb450f62cc9@haskell.org> #10165: Win32 broken with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc3 (other) | Keywords: Win32 Resolution: fixed | Architecture: x86 Operating System: Windows | Test Case: Type of failure: Runtime crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Thanks! Merged to both `master` and `ghc-7.10` (via 2ff68c3589af86811f65991c71f33282e0e50778 & 47cd08ab94e0a9bae3d9e966777616230d4fb4ff). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 21:29:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 21:29:50 -0000 Subject: [GHC] #9964: GHC crash with NOINLINE and weird IO stuff In-Reply-To: <045.9a8dda45bf1bf3aa22c69d27e354c51f@haskell.org> References: <045.9a8dda45bf1bf3aa22c69d27e354c51f@haskell.org> Message-ID: <060.59e73c669d88f94d8e33cc279d529cf6@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | codeGen/should_compile/T9964 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mietek): Similarly, 32-bit [https://downloads.haskell.org/~ghc/7.8.3/ghc-7.8.3-i386 -unknown-linux-centos65.tar.xz GHC 7.8.3] segfaults ? however, not when compiling the `Cabal` library, but the `cabal-install` executable: {{{ ... Configuring cabal-install-1.22.0.0... Building cabal-install-1.22.0.0... Preprocessing executable 'cabal' for cabal-install-1.22.0.0... [ 1 of 77] Compiling Distribution.Client.Dependency.Modular.Version ( Distribution/Client/Dependency/Modular/Version.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Version.o ) [ 2 of 77] Compiling Distribution.Client.Dependency.Modular.PSQ ( Distribution/Client/Dependency/Modular/PSQ.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/PSQ.o ) [ 3 of 77] Compiling Distribution.Client.Dependency.Modular.Package ( Distribution/Client/Dependency/Modular/Package.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Package.o ) [ 4 of 77] Compiling Distribution.Client.Compat.ExecutablePath ( Distribution/Client/Compat/ExecutablePath.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Compat/ExecutablePath.o ) [ 5 of 77] Compiling Distribution.Client.Haddock ( Distribution/Client/Haddock.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Haddock.o ) [ 6 of 77] Compiling Distribution.Client.Compat.Environment ( Distribution/Client/Compat/Environment.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Compat/Environment.o ) [ 7 of 77] Compiling Distribution.Client.PackageUtils ( Distribution/Client/PackageUtils.hs, dist/build/cabal/cabal- tmp/Distribution/Client/PackageUtils.o ) [ 8 of 77] Compiling Distribution.Client.World ( Distribution/Client/World.hs, dist/build/cabal/cabal- tmp/Distribution/Client/World.o ) [ 9 of 77] Compiling Distribution.Client.ParseUtils ( Distribution/Client/ParseUtils.hs, dist/build/cabal/cabal- tmp/Distribution/Client/ParseUtils.o ) [10 of 77] Compiling Distribution.Client.BuildReports.Types ( Distribution/Client/BuildReports/Types.hs, dist/build/cabal/cabal- tmp/Distribution/Client/BuildReports/Types.o ) [11 of 77] Compiling Distribution.Client.Compat.FilePerms ( Distribution/Client/Compat/FilePerms.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Compat/FilePerms.o ) [12 of 77] Compiling Distribution.Client.GZipUtils ( Distribution/Client/GZipUtils.hs, dist/build/cabal/cabal- tmp/Distribution/Client/GZipUtils.o ) [13 of 77] Compiling Distribution.Client.Compat.Semaphore ( Distribution/Client/Compat/Semaphore.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Compat/Semaphore.o ) [14 of 77] Compiling Distribution.Client.JobControl ( Distribution/Client/JobControl.hs, dist/build/cabal/cabal- tmp/Distribution/Client/JobControl.o ) [15 of 77] Compiling Distribution.Client.Compat.Process ( Distribution/Client/Compat/Process.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Compat/Process.o ) [16 of 77] Compiling Distribution.Client.PackageIndex ( Distribution/Client/PackageIndex.hs, dist/build/cabal/cabal- tmp/Distribution/Client/PackageIndex.o ) [17 of 77] Compiling Distribution.Client.Types ( Distribution/Client/Types.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Types.o ) [18 of 77] Compiling Distribution.Client.Dependency.Modular.Flag ( Distribution/Client/Dependency/Modular/Flag.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Flag.o ) [19 of 77] Compiling Distribution.Client.Dependency.Modular.Dependency ( Distribution/Client/Dependency/Modular/Dependency.hs, dist/build/cabal /cabal-tmp/Distribution/Client/Dependency/Modular/Dependency.o ) [20 of 77] Compiling Distribution.Client.Dependency.Modular.Tree ( Distribution/Client/Dependency/Modular/Tree.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Tree.o ) [21 of 77] Compiling Distribution.Client.Dependency.Modular.Index ( Distribution/Client/Dependency/Modular/Index.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Index.o ) [22 of 77] Compiling Distribution.Client.Dependency.Modular.Builder ( Distribution/Client/Dependency/Modular/Builder.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Builder.o ) [23 of 77] Compiling Distribution.Client.Dependency.Modular.Message ( Distribution/Client/Dependency/Modular/Message.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Message.o ) [24 of 77] Compiling Distribution.Client.Dependency.Modular.Configured ( Distribution/Client/Dependency/Modular/Configured.hs, dist/build/cabal /cabal-tmp/Distribution/Client/Dependency/Modular/Configured.o ) [25 of 77] Compiling Distribution.Client.Dependency.Modular.Assignment ( Distribution/Client/Dependency/Modular/Assignment.hs, dist/build/cabal /cabal-tmp/Distribution/Client/Dependency/Modular/Assignment.o ) [26 of 77] Compiling Distribution.Client.Dependency.Modular.Validate ( Distribution/Client/Dependency/Modular/Validate.hs, dist/build/cabal /cabal-tmp/Distribution/Client/Dependency/Modular/Validate.o ) [27 of 77] Compiling Distribution.Client.Dependency.TopDown.Types ( Distribution/Client/Dependency/TopDown/Types.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/TopDown/Types.o ) [28 of 77] Compiling Distribution.Client.Dependency.Modular.IndexConversion ( Distribution/Client/Dependency/Modular/IndexConversion.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/IndexConversion.o ) [29 of 77] Compiling Distribution.Client.Init.Licenses ( Distribution/Client/Init/Licenses.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Init/Licenses.o ) [30 of 77] Compiling Distribution.Client.Init.Types ( Distribution/Client/Init/Types.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Init/Types.o ) [31 of 77] Compiling Distribution.Client.Compat.Time ( Distribution/Client/Compat/Time.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Compat/Time.o ) [32 of 77] Compiling Distribution.Client.Tar ( Distribution/Client/Tar.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Tar.o ) [33 of 77] Compiling Paths_cabal_install ( dist/build/autogen/Paths_cabal_install.hs, dist/build/cabal/cabal- tmp/Paths_cabal_install.o ) [34 of 77] Compiling Distribution.Client.HttpUtils ( Distribution/Client/HttpUtils.hs, dist/build/cabal/cabal- tmp/Distribution/Client/HttpUtils.o ) [35 of 77] Compiling Distribution.Client.FetchUtils ( Distribution/Client/FetchUtils.hs, dist/build/cabal/cabal- tmp/Distribution/Client/FetchUtils.o ) [36 of 77] Compiling Distribution.Client.Utils ( Distribution/Client/Utils.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Utils.o ) [37 of 77] Compiling Distribution.Client.Init.Heuristics ( Distribution/Client/Init/Heuristics.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Init/Heuristics.o ) [38 of 77] Compiling Distribution.Client.IndexUtils ( Distribution/Client/IndexUtils.hs, dist/build/cabal/cabal- tmp/Distribution/Client/IndexUtils.o ) [39 of 77] Compiling Distribution.Client.Sandbox.Index ( Distribution/Client/Sandbox/Index.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Sandbox/Index.o ) [40 of 77] Compiling Distribution.Client.InstallPlan ( Distribution/Client/InstallPlan.hs, dist/build/cabal/cabal- tmp/Distribution/Client/InstallPlan.o ) [41 of 77] Compiling Distribution.Client.Dependency.Types ( Distribution/Client/Dependency/Types.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Types.o ) [42 of 77] Compiling Distribution.Client.Dependency.Modular.Log ( Distribution/Client/Dependency/Modular/Log.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Log.o ) [43 of 77] Compiling Distribution.Client.Dependency.Modular.Explore ( Distribution/Client/Dependency/Modular/Explore.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Explore.o ) [44 of 77] Compiling Distribution.Client.Dependency.Modular.Preference ( Distribution/Client/Dependency/Modular/Preference.hs, dist/build/cabal /cabal-tmp/Distribution/Client/Dependency/Modular/Preference.o ) [45 of 77] Compiling Distribution.Client.Dependency.Modular.Solver ( Distribution/Client/Dependency/Modular/Solver.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/Solver.o ) [46 of 77] Compiling Distribution.Client.Dependency.Modular.ConfiguredConversion ( Distribution/Client/Dependency/Modular/ConfiguredConversion.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular/ConfiguredConversion.o ) [47 of 77] Compiling Distribution.Client.Dependency.Modular ( Distribution/Client/Dependency/Modular.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/Modular.o ) [48 of 77] Compiling Distribution.Client.BuildReports.Anonymous ( Distribution/Client/BuildReports/Anonymous.hs, dist/build/cabal/cabal- tmp/Distribution/Client/BuildReports/Anonymous.o ) [49 of 77] Compiling Distribution.Client.BuildReports.Storage ( Distribution/Client/BuildReports/Storage.hs, dist/build/cabal/cabal- tmp/Distribution/Client/BuildReports/Storage.o ) [50 of 77] Compiling Distribution.Client.BuildReports.Upload ( Distribution/Client/BuildReports/Upload.hs, dist/build/cabal/cabal- tmp/Distribution/Client/BuildReports/Upload.o ) [51 of 77] Compiling Distribution.Client.Dependency.TopDown.Constraints ( Distribution/Client/Dependency/TopDown/Constraints.hs, dist/build/cabal /cabal-tmp/Distribution/Client/Dependency/TopDown/Constraints.o ) [52 of 77] Compiling Distribution.Client.Dependency.TopDown ( Distribution/Client/Dependency/TopDown.hs, dist/build/cabal/cabal- tmp/Distribution/Client/Dependency/TopDown.o ) ./bootstrap.sh: line 288: 4943 Segmentation fault (core dumped) ./Setup build ${EXTRA_BUILD_OPTS} ${VERBOSE} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 21:30:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 21:30:49 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.1d7cdaccd480448f21d731c4e51bb11b@haskell.org> #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: task | thoughtpolice Priority: low | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => task Comment: From Phab:D694: "If there still are broken binutils around, then maybe we should simply leave the current code (which works) in for another 10 years." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 21:41:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 21:41:01 -0000 Subject: [GHC] #9964: GHC crash with NOINLINE and weird IO stuff In-Reply-To: <045.9a8dda45bf1bf3aa22c69d27e354c51f@haskell.org> References: <045.9a8dda45bf1bf3aa22c69d27e354c51f@haskell.org> Message-ID: <060.0e755456e5a7ba4e43b56621e295738c@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | codeGen/should_compile/T9964 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mietek): And finally, 32-bit [https://downloads.haskell.org/~ghc/7.8.2/ghc-7.8.2-i386-unknown-linux- centos65.tar.xz GHC 7.8.2] ''also'' segfaults: {{{ ... Configuring Cabal-1.22.0.0... Building Cabal-1.22.0.0... Preprocessing library Cabal-1.22.0.0... [ 1 of 80] Compiling Paths_Cabal ( dist/build/autogen/Paths_Cabal.hs, dist/build/Paths_Cabal.o ) [ 2 of 80] Compiling Distribution.TestSuite ( Distribution/TestSuite.hs, dist/build/Distribution/TestSuite.o ) [ 3 of 80] Compiling Distribution.Simple.PreProcess.Unlit ( Distribution/Simple/PreProcess/Unlit.hs, dist/build/Distribution/Simple/PreProcess/Unlit.o ) [ 4 of 80] Compiling Distribution.GetOpt ( Distribution/GetOpt.hs, dist/build/Distribution/GetOpt.o ) [ 5 of 80] Compiling Distribution.PackageDescription.Utils ( Distribution/PackageDescription/Utils.hs, dist/build/Distribution/PackageDescription/Utils.o ) [ 6 of 80] Compiling Distribution.Simple.CCompiler ( Distribution/Simple/CCompiler.hs, dist/build/Distribution/Simple/CCompiler.o ) [ 7 of 80] Compiling Distribution.Compat.ReadP ( Distribution/Compat/ReadP.hs, dist/build/Distribution/Compat/ReadP.o ) [ 8 of 80] Compiling Distribution.Text ( Distribution/Text.hs, dist/build/Distribution/Text.o ) [ 9 of 80] Compiling Distribution.Version ( Distribution/Version.hs, dist/build/Distribution/Version.o ) [10 of 80] Compiling Language.Haskell.Extension ( Language/Haskell/Extension.hs, dist/build/Language/Haskell/Extension.o ) ./bootstrap.sh: line 288: 6161 Segmentation fault (core dumped) ./Setup build ${EXTRA_BUILD_OPTS} ${VERBOSE} }}} To summarise, on 32-bit RHEL 6 ? 1. Bootstrapping ''cabal-install'' 1.20.0.3 '''fails''' with GHC 7.8.4 and 7.8.3, '''but''' succeeds with GHC 7.8.2. 2. Bootstrapping ''cabal-install'' 1.22.0.0 '''fails''' with GHC 7.8.4, 7.8.3, '''and''' 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 21:54:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 21:54:52 -0000 Subject: [GHC] #10172: Cross-platform sed Message-ID: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> #10172: Cross-platform sed -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build | Version: 7.11 System | Operating System: Solaris Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It's quite easy to accidentally use GNU extensions in sed expressions, which means Solaris builds start failing. See https://phabricator.haskell.org/D740 for an example. What should we do? Here are a few possibilities: * Force use of POSIX sed with `--posix` flag. I haven't tested, but maybe this won't work if Solaris sed chokes on the `--posix`. Alternately, use `$(SED)` and add `--posix` only if it's supported * Detect GNU sed in autoconfigure and use `$(SED)` in all Makefile scripts * Stop using sed in the scripts for something else I don't know if this admonition applies to other random POSIX tools we use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 21:55:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 21:55:59 -0000 Subject: [GHC] #5376: Quotation in System.Process.system for Windows In-Reply-To: <046.28ab560abfd5d4e05c3ec95f2d90666b@haskell.org> References: <046.28ab560abfd5d4e05c3ec95f2d90666b@haskell.org> Message-ID: <061.428d13c4d82f7d01075bd4361beec9a2@haskell.org> #5376: Quotation in System.Process.system for Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: snoyberg Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 7.0.4 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 22:00:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 22:00:47 -0000 Subject: [GHC] #10172: Cross-platform sed In-Reply-To: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> References: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> Message-ID: <060.9f10c00b3fa4ca2bbb15c48f853cacbb@haskell.org> #10172: Cross-platform sed -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kgardas): Solaris sed does not support --posix. Please note I'm using sed from /usr/xpg4/bin -- which means this should be posix compliant sed. Also so far we've always been able to come with some posix compliant solution. Perhaps even for this someone will find one. I'll have some time to deal with it during the weekend hopefully... Anyway, so I'm for (1) use POSIX sed features only, although --posix command-line option is pure GNU-ism probably. When this really does not work, then switch to (2) require GNU sed and so in makefiles use $(SED) and provide appropriate configure.ac machinery for this... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 22:11:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 22:11:08 -0000 Subject: [GHC] #10172: Cross-platform sed In-Reply-To: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> References: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> Message-ID: <060.688f8e3997c0d18d1677dd9c74fefd6b@haskell.org> #10172: Cross-platform sed -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): If I understand correctly, there is no way to get EREs from POSIX sed. It would be really nice to have a way of clamping to POSIX-only even on Linux; makes it less likely for devs to mess it up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 22:20:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 22:20:46 -0000 Subject: [GHC] #8150: Foreign export requires redundant type signature In-Reply-To: <054.121fc89ce6d748a9894a6634502aeaaf@haskell.org> References: <054.121fc89ce6d748a9894a6634502aeaaf@haskell.org> Message-ID: <069.61e9911adf5ec64310a0f025c75e80fd@haskell.org> #8150: Foreign export requires redundant type signature -------------------------------------+------------------------------------- Reporter: evincarofautumn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 22:41:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 22:41:17 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.d1bee0290ef1bbc6afcec0df06fd5017@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D625 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e02ef0e6d4eefa5f065cc1c33795dfa2114cd58e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e02ef0e6d4eefa5f065cc1c33795dfa2114cd58e" testsuite: add a regression test for #10011 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 22:42:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 22:42:40 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.ae1205710a050e435b375020638f1248@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | tests/numeric/should_run/T10011 Related Tickets: | Blocking: | Differential Revisions: Phab:D625 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * testcase: => tests/numeric/should_run/T10011 * resolution: => fixed Comment: Testcase added and merged into `ghc-7.10` and `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 22:54:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 22:54:17 -0000 Subject: [GHC] #10171: runghc has problem when the argument list is too big In-Reply-To: <045.96454332beb6fa9e279ce43759cb41f3@haskell.org> References: <045.96454332beb6fa9e279ce43759cb41f3@haskell.org> Message-ID: <060.099b9df1dc8c5ca5ff0a33047a5a7ea9@haskell.org> #10171: runghc has problem when the argument list is too big -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: POSIX | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7980 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by redneb): What about adding a new flag to `ghc`, say `--run`, that would make it work like `runghc`, e.g. {{{ ghc --run script.hs arg1 arg2 }}} and also make `ghc` add the flag automatically to its arguments when invoked as `runghc` so that we could make `runghc` (and `runhaskell` of course) as simple symlink to `ghc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 23:17:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 23:17:09 -0000 Subject: [GHC] #8150: Foreign export requires redundant type signature In-Reply-To: <054.121fc89ce6d748a9894a6634502aeaaf@haskell.org> References: <054.121fc89ce6d748a9894a6634502aeaaf@haskell.org> Message-ID: <069.a08c45fc6f9297ecd61e98cd78a1fec4@haskell.org> #8150: Foreign export requires redundant type signature -------------------------------------+------------------------------------- Reporter: evincarofautumn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The types aren't actually required to be the ''same'', though, as this is accepted too (even with `-Wall`): {{{ module FFITest where foreign export ccall "function" function :: IO () function :: IO a function = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 19 23:35:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Mar 2015 23:35:25 -0000 Subject: [GHC] #10121: operational semantics is incomplete? In-Reply-To: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> References: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> Message-ID: <060.c93f7b9c16e8edd707f436ff95458625@haskell.org> #10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darchon): Sorry for the shameless self-plug... but perhaps check out Appendix C of: http://doc.utwente.nl/93962/1/thesis_C_Baaij.pdf It's System FC + Letrec + Case... very much like Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 20 00:08:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Mar 2015 00:08:11 -0000 Subject: [GHC] #10121: operational semantics is incomplete? In-Reply-To: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> References: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> Message-ID: <060.de2a6d3465fa8772c992e2810222b63a@haskell.org> #10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Cool beans. Thanks for posting that. After a quick look-through, the rules around letrec there look quite promising. At least Christiaan has a proof that they work, unlike the system in core-spec. @javran, thoughts? If these look good to you, I'll rewrite core-spec accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 20 01:03:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Mar 2015 01:03:03 -0000 Subject: [GHC] #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just Message-ID: <045.560814a380f9a1315a0b9eab831acc66@haskell.org> #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just -----------------------------------+--------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------------- On 32-bit Red Hat Enterprise Linux 6.5, released on 11/11/2014 (available on [https://aws.amazon.com/marketplace/pp/B007NMF9O0/ Amazon EC2]), building `attoparsec-0.12.1.2` with GHC 7.8.4 causes a panic: {{{ Configuring attoparsec-0.12.1.2... Building attoparsec-0.12.1.2... Preprocessing library attoparsec-0.12.1.2... [ 1 of 21] Compiling Data.Attoparsec.Text.FastSet ( Data/Attoparsec/Text/FastSet.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Text/FastSet.o ) [ 2 of 21] Compiling Data.Attoparsec.Text.Buffer ( Data/Attoparsec/Text/Buffer.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Text/Buffer.o ) [ 3 of 21] Compiling Data.Attoparsec.Internal.Fhthagn ( Data/Attoparsec/Internal/Fhthagn.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Internal/Fhthagn.o ) [ 4 of 21] Compiling Data.Attoparsec.ByteString.Buffer ( Data/Attoparsec/ByteString/Buffer.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/ByteString/Buffer.o ) [ 5 of 21] Compiling Data.Attoparsec.Zepto ( Data/Attoparsec/Zepto.hs, dist/dist-sandbox-a9165fb6/build/Data/Attoparsec/Zepto.o ) [ 6 of 21] Compiling Data.Attoparsec.Number ( Data/Attoparsec/Number.hs, dist/dist-sandbox-a9165fb6/build/Data/Attoparsec/Number.o ) [ 7 of 21] Compiling Data.Attoparsec.ByteString.FastSet ( Data/Attoparsec/ByteString/FastSet.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/ByteString/FastSet.o ) [ 8 of 21] Compiling Data.Attoparsec.Internal.Types ( Data/Attoparsec/Internal/Types.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Internal/Types.o ) [ 9 of 21] Compiling Data.Attoparsec.Types ( Data/Attoparsec/Types.hs, dist/dist-sandbox-a9165fb6/build/Data/Attoparsec/Types.o ) [10 of 21] Compiling Data.Attoparsec.Internal ( Data/Attoparsec/Internal.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Internal.o ) [11 of 21] Compiling Data.Attoparsec.Combinator ( Data/Attoparsec/Combinator.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Combinator.o ) [12 of 21] Compiling Data.Attoparsec.ByteString.Internal ( Data/Attoparsec/ByteString/Internal.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/ByteString/Internal.o ) [13 of 21] Compiling Data.Attoparsec.Text.Internal ( Data/Attoparsec/Text/Internal.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Text/Internal.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for i386-unknown-linux): compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs:84:13-59: Irrefutable pattern failed for pattern Data.Maybe.Just live_set }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 20 01:05:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Mar 2015 01:05:34 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.e506748e5bf90f37ab0f145698508139@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): @thomie That would work for some cases, but imo, if `llc-3.6` does not exist, the configure script should still check to see if `llc` is the required version. @rwbarton I agree about not looking for `/usr/lib/llvm-3.6/bin/llc`. That was a silly idea. @nomeata That may be true, but we still need to fix this for people compiling from git. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 20 02:58:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Mar 2015 02:58:41 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.be8748f684bfdc6294627c2654672705@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (LLVM) | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by altaic): FYI, I pinged the LLVM guys for clarification-- http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083754.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 20 04:14:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Mar 2015 04:14:54 -0000 Subject: [GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel Message-ID: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Building GHC Test Case: | failed Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Compiling git HEAD (e02ef0e6d4eefa5f0) on AArch64 hardware using ghc-7.6.3 from Debian as the bootstrap compiler. LLVM is version 3.6. It fails with: {{{ "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fllvm \ -this-package-key paral_2NTMt5X9WUG6LNupBFIZti -hide-all-packages -i \ -ilibraries/parallel/. -ilibraries/parallel/dist-install/build \ -ilibraries/parallel/dist-install/build/autogen \ -Ilibraries/parallel/dist-install/build \ -Ilibraries/parallel/dist-install/build/autogen -Ilibraries/parallel/. \ -optP-include -optPlibraries/parallel/dist- install/build/autogen/cabal_macros.h \ -package-key array_BLJREAlFJ4zJ2kSDphVieY -package-key base_8gvrDSBdaidLA14EDtK6ja \ -package-key conta_1uqbEcrmZiO1C91Z8ePoyI -package-key deeps_Bw45clVBNVT4S1LLyUOPfh \ -Wall -feager-blackholing -XHaskell2010 -O -fllvm -no-user-package- db -rtsopts \ -odir libraries/parallel/dist-install/build \ -hidir libraries/parallel/dist-install/build \ -stubdir libraries/parallel/dist-install/build \ -dynamic-too -c libraries/parallel/./Control/Parallel/Strategies.hs \ -o libraries/parallel/dist- install/build/Control/Parallel/Strategies.o \ -dyno libraries/parallel/dist- install/build/Control/Parallel/Strategies.dyn_o libraries/parallel/ghc.mk:5: recipe for target 'libraries/parallel/dist-install/build/Control/Parallel/Strategies.o' failed make[1]: *** [libraries/parallel/dist- install/build/Control/Parallel/Strategies.o] Segmentation fault }}} It seems that `inplace/lib/bin/ghc-stage1` (which is working fine) is statically linked to all the Haskell libraries where as `inplace/lib/bin /ghc-stage2` is dynamically linked which would explain why stage1 works fine and stage2 segfaults. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 20 04:57:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Mar 2015 04:57:11 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.ffdc30a97eabb5c98b9b7292efd68290@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by liyang): * cc: ghc.haskell.org@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 20 18:09:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Mar 2015 18:09:38 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.ae14b7169952ccd786a058d82d2ede79@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731 -------------------------------------+------------------------------------- Comment (by trommler): Removing patch state. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 20 21:00:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Mar 2015 21:00:49 -0000 Subject: [GHC] #10175: User's Guide 7.4.4 ExplicitTypeOperators typo Message-ID: <043.b535f2862d0e2897a77c4244ce1cf331@haskell.org> #10175: User's Guide 7.4.4 ExplicitTypeOperators typo -------------------------------------+------------------------------------- Reporter: Shou | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 Documentation | Operating System: Unknown/Multiple Keywords: typo | Type of failure: None/Unknown extension | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- > There is now some potential ambiguity in import and export lists; for example if you write import M( (+) ) do you mean the function (+) or the type constructor (+)? The default is the former, but with -XExplicitNamespaces (which is implied by -XExplicitTypeOperators) GHC allows you to specify the latter by preceding it with the keyword type, thus: [...] GHC lists no extension `-XExplicitTypeOperators`, so it is assumed to be a mistake intended to be `-XTypeOperators`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 20 23:36:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Mar 2015 23:36:29 -0000 Subject: [GHC] #10121: operational semantics is incomplete? In-Reply-To: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> References: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> Message-ID: <060.761de126fc6b416ef23c82632af75d0f@haskell.org> #10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by javran): Thanks @darchon @goldfire that looks good to me :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 06:32:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 06:32:42 -0000 Subject: [GHC] #8379: sync-all broken when using the GitHub mirror In-Reply-To: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> References: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> Message-ID: <059.5d46084a0e3aa5a36b9e4544773886cc@haskell.org> #8379: sync-all broken when using the GitHub mirror -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8667 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tibbe): * status: new => closed * resolution: => fixed Comment: sync-all is no longer needed as we're now on an all-git setup with submodules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 08:35:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 08:35:28 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 Message-ID: <051.8795776bc89448b822d3578207722ec2@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using the Shake repo (https://github.com/ndmitchell/shake.git) at commit d7fa04 and GHC 7.10 RC3 or GHC HEAD, if I {{cabal test}} I get the error: {{{ ## BUILD oracle --quiet *str-int TESTS FAILED shake-test: Expected an exception but succeeded }}} Discussion about this issue can be found on the mailing list: http://osdir.com/ml/general/2015-03/msg25847.html GHC generates the Core: {{{ case (\_ -> error "here") of {} }}} This is invalid GHC Core. I intend to track down a minimal example shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 09:24:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 09:24:05 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.4edfdace2104b267889910811c406552@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): I've been doing some hacking on this and here is my current solution (for now `X.Y` is `3.6`): * The configure script should check for `llc-X.Y` and `opt-X.Y` *before* it checks for plain `llc` and `opt`. * Only check for plain `llc` and `opt` if the explicitly versioned ones are not found. * If it finds plain `llc` and `opt` check that the version is `X.Y`. The above currently works, but causes other problems in this check: {{{ checking whether bootstrap compiler is affected by bug 9439... You are using a new version of LLVM that hasn't been tested yet! We will try though... /usr/bin/opt-3.6: /tmp/ghc12163_0/ghc12163_2.ll:7:6: error: unexpected type in metadata definition !0 = metadata !{metadata !"top", i8* null} ^ failed to compile }}} The problem here is that this checks the bootstrap compiler bug using the detected `LlcCmd` (which now *must* be `llc-3.6`) which doesn't support he LLVM IR syntax above. I think is in-correct. The bootstrap compiler should already have the location of the `llc` and `opt` it was compiled for in its `settings` file (these have been present in that file since ghc 7.6 but they are not present in eg 7.4.2). Its the llc version in the settings file which should be checked for bug #9439, not the one detected by the configure script. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 09:45:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 09:45:25 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.b313869ef21a16ab22192eedd8f6bcb5@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): That's easy to fix. Revert this change I made in 1dfab7a8ace5f09f00f8fb695932b4324e88b822: {{{ \--- a/configure.ac +++ b/configure.ac @@ -508,7 +508,7 @@ then echo "main = putStrLn \"%function\"" > conftestghc.hs # Check whether LLVM backend is default for this platform - "${WithGhc}" conftestghc.hs 2>&1 >/dev/null + "${WithGhc}" -pgmlc="${LlcCmd}" -pgmlo="${OptCmd}" conftestghc.hs 2>&1 >/dev/null res=`./conftestghc` if test "x$res" = "x%object" then @@ -525,7 +525,7 @@ then # -fllvm is not the default, but set a flag so the Makefile can check # -for it in the build flags later on - "${WithGhc}" -fforce-recomp -fllvm conftestghc.hs 2>&1 >/dev/null + "${WithGhc}" -fforce-recomp -pgmlc="${LlcCmd}" -pgmlo="${OptCmd}" -fllvm conftestghc.hs 2>&1 >/dev/null if test $? = 0 then res=`./conftestghc` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 11:17:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 11:17:02 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.b7032cb757fca998fdb24e16095c5044@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D745 -------------------------------------+------------------------------------- Changes (by erikd): * differential: => D745 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 11:37:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 11:37:01 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.aa317b30ac94dc69b22994c8c68db894@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Fyi, I scripted up a test and git-bisected between RC2 and RC3, and the 6f46fe15af397d448438c6b93babcdd68dd78df8 commit is the one where `shake- test oracle test` starts failing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 11:40:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 11:40:44 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.c41a6b7839fadb26a01d57cff9170fc3@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * version: 7.8.4 => 7.10.1-rc3 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 11:49:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 11:49:18 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.9c36c6e2c21811f2296ab21389095ceb@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): Running {{{ghc -outputdir obj -O -ddump-simpl Buggy.hs}}} produces the output: {{{ case (\ _ [Occ=Dead] _ [Occ=Dead, OS=OneShot] -> case lvl_r1lh unit_XyJ of wild2_00 { }) `cast` ((<()>_R -> Sym (GHC.Types.NTCo:IO[0] _R)) ; Sym (Buggy.NTCo:ReaderT[0] <()>_R _R) :: (() -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Any #)) ~R# ReaderT () GHC.Prim.Any) of _ [Occ=Dead] { } }}} Ignoring the cast (which I don't think is relevant) that is: {{{ case (\_ _ -> ...) of {} }}} I've reduced the bug so the code only depends on {{{Prelude}}}, requiring no external libraries. I have not been able to remove the requirement for two modules. The partial implementation of {{{ReaderT}}} is taken from the {{{transformers}}} library then specialised to {{{IO}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 13:06:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 13:06:56 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.d7c47581a6f36dae2b89dfb99121ada4@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D745 -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: D745 => Phab:D745 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 13:28:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 13:28:29 -0000 Subject: [GHC] #9261: -S prints incorrect number of bound tasks In-Reply-To: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> References: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> Message-ID: <059.2327d790ca6c5620b441190a92ae270a@haskell.org> #9261: -S prints incorrect number of bound tasks -------------------------------------+------------------------------------- Reporter: edsko | Owner: thomie Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D746 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D746 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 13:32:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 13:32:37 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.7c80e30524c408ddf18713ce65408eb5@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Fwiw, I see GHC 7.8.4 producing similiar Core (with `-dsuppress-all -dsuppress-uniques`): {{{#!hs a = \ fun unit1 bool eta -> case bool of _ { False -> case fun unit1 of _ { False -> (# eta, () #); True -> case m of wild2 { } }; True -> case hPutStr2 stdout shows3 True eta of _ { (# ipv, ipv1 #) -> case fun unit1 of _ { False -> (# ipv, () #); True -> case m of wild2 { } } } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 13:36:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 13:36:10 -0000 Subject: [GHC] #9261: -S prints incorrect number of bound tasks In-Reply-To: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> References: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> Message-ID: <059.eec301ca2a4dc2e2f5c425fb8b48fd3c@haskell.org> #9261: -S prints incorrect number of bound tasks -------------------------------------+------------------------------------- Reporter: edsko | Owner: thomie Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D746 -------------------------------------+------------------------------------- Comment (by edsko): I'm not sure to be honest. I reported this because I (thought I) was getting incorrect numbers reported, not because I was looking at the source code. I was looking at the source code only _because_ I was getting strange numbers. But I've forgotten the details; if you're sure it's correct.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 13:49:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 13:49:06 -0000 Subject: [GHC] #9261: -S prints incorrect number of bound tasks In-Reply-To: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> References: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> Message-ID: <059.0975d5d2b239da3a1ee292a1d5472185@haskell.org> #9261: -S prints incorrect number of bound tasks -------------------------------------+------------------------------------- Reporter: edsko | Owner: thomie Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D746 -------------------------------------+------------------------------------- Comment (by thomie): Well, I've only studied the source code, I didn't actually run anything.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 14:32:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 14:32:09 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.a109c941b7738998bfda58db0df3d4a1@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): That's quite different since (after inlining a few bits): {{{ $wlvl $wlvl = \ _ -> error "here" m = $wlvl void# }}} So {{{m}}} evaluates to {{{_|_}}} in GHC 7.8 which means a case with no alternatives is correct. However, in 7.10 the scrutinee evaluates to a lambda, not {{{_|_}}}, so no alternatives is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 14:36:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 14:36:45 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.070b000c3c48bfa40047456b09524993@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): After adding a lint check as suggested by SPJ, I simplified your example to {{{ module Buggy(buggy) where {-# NOINLINE error1Arg #-} error1Arg :: () -> a error1Arg _ = undefined {-# NOINLINE buggy #-} buggy :: a buggy = error1Arg () () }}} but I?m not sure if the lint check is actually correct here, as this is the core it complains about: {{{ *** Core Lint errors : in result of Simplifier *** Buggy.hs:9:10: Warning: [in body of lambda with binder a_an8 :: *] No alternatives for HNF scrutinee error1Arg @ (() -> a_an8) () *** Offending Program *** error1Arg [InlPrag=NOINLINE] :: forall a_an0. () -> a_an0 [LclId, Arity=2, CallArity=2, Str=DmdType b] error1Arg = \ (@ a_anf) _ [Occ=Dead, Dmd=] -> undefined @ a_anf buggy [InlPrag=NOINLINE] :: forall a_amZ. a_amZ [LclIdX, Str=DmdType b] buggy = \ (@ a_an8) -> case error1Arg @ (() -> a_an8) () of wild_00 { } *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 14:42:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 14:42:18 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.ad760033ceb75171877b91ca0d680fad@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Eek. This seems to be my fault: Note the `CallArity=2`. And indeed, with `-fno-call-arity` this passes; same for your test case. :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 14:46:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 14:46:48 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.43cfa8f875779b83838bfedc146c6bd5@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): I was expecting a simple pattern match on {{{(Case Lam{} _ _ [])}}}, what does your diff look like? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 14:47:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 14:47:44 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.2cdb21544a2395c08b3b0dfc5f4fedc1@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Ok, I think here is what happens, at least in my smaller test case: 1. Call Arity determines that `error1Arg` is always called with two arguments. Hence `CallArity=2`. This is correct. 2. The simplifier tries to eta-expand `error1Arg` to take two arguments. This fails in `mkEtaWW` in `CoreArity`, where we have this comment: {{{ -- This *can* legitmately happen: -- e.g. coerce Int (\x. x) Essentially the programmer is -- playing fast and loose with types (Happy does this a lot). -- So we simply decline to eta-expand. Otherwise we'd end up -- with an explicit lambda having a non-function type }}} 3. But still, the `Arity` field is updated. 4. Since it has `Arity=2`, `exprIsHNF (error1Arg @ _ ())` is true, and the simplifier does strange things. So maybe the solution is to ''not'' update `Arity` with the result from Call Arity, but instead let eta-expansion happen and update `Arity` with the manifest arity after eta expansion. I?ll try that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 15:06:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 15:06:07 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.2cdf4f042b15e34f938a857d79704ada@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Ok, I might have found a suitable fix. You can have a look at Phab:D747, although it?s still pending validation (and the new lint check might yet uncover other problems). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 15:16:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 15:16:33 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.0588beeee8d0823bc97dab585abf6196@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Or not quite. I think I did find a bug, but not the only one: With the change in Phab:D747, my small example and your example, when merged into one module, no longer fail. But your original test case still fails with Call Arity, and compiles fine without. There still seems to be some fishiness with Call Arity and `undefined`. /me continues brooding over the Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 15:18:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 15:18:03 -0000 Subject: [GHC] #10121: operational semantics is incomplete? In-Reply-To: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> References: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> Message-ID: <060.74ec211708dc09ef37b42854a277b6ae@haskell.org> #10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darchon): Yeah... those rules are the only ones I could think of and stay within the domain of the original small-step semantics of System FC. Another way to go about it is to add an explicit heap to the semantics, and put let- bindings to that heap, ala "a natural semantics for lazy evaluation". But then you'd have to update all the other rules also. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 15:21:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 15:21:31 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.1f84965bd988ee199b5f1438ad1ffa5d@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): not sure if this is useful information, but I compared the output of {{{ ghc -fforce-recomp -outputdir obj -O -ddump-simpl -dsuppress-uniques Buggy.hs }}} for acbfc19a6d27b51aaec5177e4b64ea9b45f74c84 (recent ghc-7.10 branch snapshot) vs. 029a296a770addbd096bbfd6de0936327ee620d4 (one commit before the big typeable-change that caused `shake-test oracle test` to start failing) And well, the Core output looks just the same, so I'm not sure if the `Buggy.hs`/`Errors.hs` test-case highlights the same issue causing `shake- test` to fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 15:23:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 15:23:25 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.49ba34184d329320905fde4638d57552@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I simplified your code slightly, removing everything about type classes: {{{ module Buggy(buggy) where import Errors newtype ReaderT r a = ReaderT { runReaderT :: r -> IO a } p = liftReaderT (return ()) m >>> k = ReaderT $ \r -> do runReaderT m r; runReaderT k r liftReaderT :: IO a -> ReaderT r a liftReaderT m = ReaderT (const m) {-# NOINLINE buggy #-} buggy :: (() -> Bool) -> () -> Bool -> IO () buggy fun unit bool = runReaderT ( (if bool then liftReaderT $ print () else p) >>> (if fun unit then error2Args unit unit >>> p else p)) () }}} still exhibits the problem. Removing the `newtype`, or turning it into a `data` makes the problem go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 18:01:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 18:01:39 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.e0ab3c0cd844aeaa9a8039aadc931b01@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 5144 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by blamario): I just ran into this issue. I'm trying to generalize a legacy record type like {{{ data Foo = Foo{bar :: String} }}} to {{{ data GenFoo s = GenFoo{bar :: s} }}} Unfortunately there is no way to provide a backward-compatible interface after this change. I'm hoping with this feature the solution might be as simple as {{{ type Foo = GenFoo String pattern Foo{bar} = GenFoo bar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 18:12:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 18:12:14 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.a51c67df1e9562f1b2193b22ea5e7a46@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Also, changing the code to {{{ newtype Fun a b = Fun { runFun :: a -> b } type ReaderT r x = Fun r (IO x) }}} makes the problem go away. Must be some weird interaction with coercions... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 19:41:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 19:41:27 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.cb08e63e2c03f9cc3061606d0f2d0c7f@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I think I found it. The problem is a bad interaction between Call Arity and simplification based on the strictness result. Consider this code: {{{ e x = error "foo" x ... case e () () of {} ... }}} The strictness signature for `e` will be `b`. Note the `b`: This means: ?If you give me one argument, then I?m going to be ?, which is true. The Call Arity for `e` is `2`, which is true: `e` is always called with two arguments. So the simplifier phase following Call Arity will replace with {{{ e x y = error "foo" x y }}} At the same time, the simplifier will replace `e () ()` with `e ()`. After all, both are known to be bottom. The result (after inlining) is the bogus {{{ ... case (\y -> error "foo" x y) of {} ... }}} that we see. The simplifier looks at the `b` flag of the strictness analyzer in `mkArgInfo`, replacing `isBotRes result_info` with `False` makes the problem go away, but that is probably not the solution. Zapping strictness analysis when Call Arity finds something is probably also a bad idea. Maybe the best solution is to limit the number found by call arity to the number of arguments in the strictness signature, if the strictness signature ends in a `b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 20:10:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 20:10:36 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.a630331838d95e89c48eb0c294b43ed2@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch Comment: Ok, validates. Does someone want to make sure I?m not talking complete nonsense before I merge this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 20:38:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 20:38:15 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.c903b3117377412d44b0b6c26568a692@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: infoneeded Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Resolution: | Keywords: Debian Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Kritzefitz: thank you for your response. I don't think there isn't anything for GHC to do here, and I'm inclined to close as invalid. What is your opinion? Here's my understanding of what's happening. I'm keeping this linux only (`sudo apt-get install libcurl4-openssl-dev` and `cabal install curl` first): * The .cabal file of the curl package specifies `extra-libraries: curl` * After cabal installing curl, this stanza ends up in curl's ghc package file (check with `ghc-pkg describe curl | grep extra-libraries`) * When you make test.hs, ghc figures out that curl is required. It parses curl's ghc package file, and extracts the extra-libraries field. When it's time for linking, it then passes `-lcurl` to the linker. * Since the linker wasn't told which version of curl it should find, it searches for a file `libcurl.so` in any of the system lib directories. On Debian/Ubuntu, as you mentioned, this unversioned file (symbolic link) is only present after installing a curl `-dev` package (1). * The linker then follows the symbolic link, and produces a binary that //is// linked to a versioned .so file (`libcurl.so.4` in my case). This is good, because that means that users of the binary will not need the `-dev` package for curl to be installed, but just the runtime package will do. The linker can be also be told to look for a specific file, by using `-l:filename` instead of `-lname` (see `man ld` and search for `--library=`). This `filename` is necessarily platform specific (e.g. dll on Windows), but cabal and ghc support this format in principal (though there seems to be a bug when doing this via ghci). Here's what I've tried: * cabal get curl && cd curl-1.3.8 * # edit curl.cabal and change `extra-libraries: curl` to `extra- libraries: libcurl.so.4` * cabal install * sudo apt-get remove libcurl4-openssl-dev * # verify that libcurl.so is no longer present * # change to directory with your test.hs * ghc test.hs It works! Responding to your issue, either: 1. Debian's should change its policy (1) 2. or the curl library should be updated 3. or users of the curl library should just install the curl -dev package (they are developers after all, not end users). (1) https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s -sharedlibs-dev -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 20:53:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 20:53:14 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.cb5aae22543737d610b405edd8505250@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Resolution: | Keywords: Debian Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: infoneeded => new Comment: It is right that the cabal file specifies only `curl` in the cabal file, after all, no specific version is required here. But after GHC has produced a `.so` file, this `.so` file, as you say, is tied to a specific version of the `curl` library. So the correct thing to do would be to store the precisely used version in the package data base. This way, building the curl bindings requires the `libcurl-dev` package, but using the curl bindings, e.g. when building a Haskell executable or from ghci, would only require the specific runtime package. This would actually make packaging Haskell for Debian a bit simpler... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 20:53:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 20:53:38 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.2bf3d828a1745cc0d56d718a2ac230e6@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Resolution: | Keywords: Debian Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): (But maybe this means that this is actually a Cabal bug?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 20:53:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 20:53:54 -0000 Subject: [GHC] #10177: Typeable solver regression Message-ID: <044.31773993d01a9acbca1586a9db429c36@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This bug is known and fixed in master. Simon and Austin and Iavor are all aware of it. This ticket exists to ensure that the fix doesn't get lost. This code breaks under the Typeable solver in 7.10.1-rc3 and is fixed in master. The relevant commit in master is 3a0019e3672097761e7ce09c811018f774febfd2 : Improve `Typeable` solver. {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE FlexibleContexts #-} module Bug where import Data.Typeable newtype V n a = V [a] class Typeable a => C a instance (Typeable (V n), Typeable a) => C (V n a) -- Bug.hs:13:10: -- Could not deduce (Typeable (V n a)) -- arising from the superclasses of an instance declaration -- from the context (Typeable (V n), Typeable a) -- bound by the instance declaration at Bug.hs:13:10-50 -- In the instance declaration for ?C (V n a)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 21:34:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 21:34:09 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.344df8b84c8c99670e1e2ca6dbfc1c24@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): To assess what does happen in this error case, I augmented the code to be: {{{ buggy fun unit bool = runReaderT (do if bool then liftReaderT $ print () else pure () if fun unit then do error2Args unit unit; liftReaderT $ print "here2" else pure () ) () :: IO () }}} Running {{{do print "here1"; buggy (const True) () True; print "here3"}}} gives {{{here1; here3}}}. GHC has used the presence of error to remove the {{{here2}}}, but since the code just falls out of the end of the function it returns back and still prints {{{here3}}}. That's a nasty result, and pretty much describes what happens in the full test case (I'm in the middle of compiling, and then suddenly I stop and do the thing that comes after compiling). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 21:39:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 21:39:40 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.39757d1c5a958eea63c93f11aef94fd7@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Resolution: | Keywords: Debian Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): You're right! curl's cabal file would still contain `extra-libraries: curl`. But when installing curl, whoever decides the parameters for the ghc-pkg file (either cabal or ghc, I don't know at the moment) could ask the linker which version it actually found, and write `extra-libraries: :libcurl.so.` to the ghc-pkg file. That should work (at least on linux). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 21:49:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 21:49:22 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.45af1ac594ebbedf769c5c4f1479b364@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I've checked Phab:D747 which looks great to me; i've made some suggestions. Maybe we can turn comment:17 into a test that not only should compile (as D747 has) but should run also. thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 21:50:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 21:50:58 -0000 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found In-Reply-To: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> References: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> Message-ID: <062.bd180142f9b989cb41afc47545e27dfb@haskell.org> #10158: Panic compiling singletons: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): I nailed this one. This diff fixes it. It was a missing 'runFlatten'. However I propose not to commit a fix, because Richard's D653 refactors all that code and, I'm 99% certain, fixes the bug in a better way. I would like D653 to land though. Richard is planning to do that on Monday Simon {{{ Modified compiler/typecheck/TcInteract.hs diff --git a/compiler/typecheck/TcInteract.hs b/compiler/typecheck/TcInteract.hs index e83709c..4d4b31c 100644 --- a/compiler/typecheck/TcInteract.hs +++ b/compiler/typecheck/TcInteract.hs @@ -1420,6 +1420,7 @@ shortCutReduction old_ev fsk ax_co fam_tc tc_args | otherwise = ASSERT( not (isDerived old_ev) ) -- Caller ensures this ASSERT( ctEvEqRel old_ev == NomEq ) + runFlatten $ do { (xis, cos) <- flattenManyNom old_ev tc_args -- ax_co :: F args ~ G tc_args -- cos :: xis ~ tc_args }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 22:25:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 22:25:26 -0000 Subject: [GHC] #9839: RTS options parser silently accepts invalid flags In-Reply-To: <049.1ac180907787acdf75c140998b5b4263@haskell.org> References: <049.1ac180907787acdf75c140998b5b4263@haskell.org> Message-ID: <064.109670e487c35034dbccc2dee791ad15@haskell.org> #9839: RTS options parser silently accepts invalid flags -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: carlostome Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #4243 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by carlostome): * owner: => carlostome -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 22:40:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 22:40:57 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.cc652ab2de16eb58867218a6575103cf@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by glguy): * status: new => closed * resolution: => fixed Comment: I just saw this was merged -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 22:49:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 22:49:56 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.31546c6f1f662dff478f06eb060e6718@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by hvr): merged to ghc-7.10 via 32a5d959ea47f0ebd3231d41d77c4dd13c138658 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 23:00:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 23:00:42 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.9d2e810cc9fd2188ad497b4d20932758@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): I can confirm that 1cc46b1fd5ce794d3a1519c65dcf4aded317598b + phab:D747 allows `shake-test oracle test` to succeed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 23:09:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 23:09:49 -0000 Subject: [GHC] #10178: hs-boot/hsig ambiguity empty data declaration or type with no constructors Message-ID: <045.b8bd218346900e499cdb43f05ac39bda@haskell.org> #10178: hs-boot/hsig ambiguity empty data declaration or type with no constructors -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I write in a boot or signature file: {{{ data Foo }}} it is ambiguous whether or not this is a fully-specified empty data declaration, or a data type which has its constructors unspecified. This doesn't matter too much for hs-boot (since you can't use the data constructors in any case) but for signatures we might want to force a data type to be empty. Though I think this case should be rare. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 21 23:14:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Mar 2015 23:14:12 -0000 Subject: [GHC] #9839: RTS options parser silently accepts invalid flags In-Reply-To: <049.1ac180907787acdf75c140998b5b4263@haskell.org> References: <049.1ac180907787acdf75c140998b5b4263@haskell.org> Message-ID: <064.0ca5f4147ec34d6ec23d626f788194ff@haskell.org> #9839: RTS options parser silently accepts invalid flags -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: carlostome Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #4243 | Differential Revisions: Phab:D748 -------------------------------------+------------------------------------- Changes (by carlostome): * status: new => patch * differential: => Phab:D748 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 01:05:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 01:05:06 -0000 Subject: [GHC] #10179: Kinds missing from types in ghci Message-ID: <042.49d0257de6eb7718086e9479b7e7019f@haskell.org> #10179: Kinds missing from types in ghci -------------------------------------+------------------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} data family F (a:: k) foo :: F (m :: [()]) -> a foo = undefined bar :: F (m :: [[()]]) -> a bar = undefined according to GHCi, both foo and bar have type F m -> a but [foo, bar] fails -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 01:13:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 01:13:33 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.c3dcc652575e4516abc7d7d57921ae68@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"854fd12358fef51848c2eb5e7e08d9c8cec43e16/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="854fd12358fef51848c2eb5e7e08d9c8cec43e16" testsuite: add test for #10177 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 01:13:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 01:13:59 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.8d4c29e99d60e6a2cacf9a0d793ce79c@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T10177 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * testcase: => testsuite/tests/typecheck/should_compile/T10177 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 08:19:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 08:19:43 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee Message-ID: <046.44e015288991066cebe38e4a3f60f704@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As suggested by SPJ in https://phabricator.haskell.org/D747?id=2498#inline-6057 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 08:21:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 08:21:13 -0000 Subject: [GHC] #10181: Lint check: arity invariant Message-ID: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The Arity of an ID should not exceed the arity of its type, nor the arity of its strictness signature, if it is a bottoming signatures. This should be checked by a lint check (suggested by SPJ in https://phabricator.haskell.org/D747?id=2498#inline-6058) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 09:02:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 09:02:44 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.b50589c7b1f2776bac2abd41163f3cd9@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * owner: => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 10:00:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 10:00:02 -0000 Subject: [GHC] #3283: Selective disabling of unused bind warnings In-Reply-To: <042.99c53619193c24de1883dd2c0ccb355d@haskell.org> References: <042.99c53619193c24de1883dd2c0ccb355d@haskell.org> Message-ID: <057.43c4bb26042d05437547d90a573fbfcf@haskell.org> #3283: Selective disabling of unused bind warnings -------------------------------------+------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #17 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: Replying to [comment:5 jstolarek]: > Now that #17 is closed can we consider this a duplicate? This ticket is about adding a `-fno-warn-unused-fields` flag. But since nomeata wasn't sure how useful this feature would be, nobody has looked at it in 5 years, and #17 is indeed implemented, I'm at least removing the newcomer keyword. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 11:13:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 11:13:10 -0000 Subject: [GHC] #9261: -S prints incorrect number of bound tasks In-Reply-To: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> References: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> Message-ID: <059.ed3c2ea16ddb16dc53ef7d58546c2263@haskell.org> #9261: -S prints incorrect number of bound tasks -------------------------------------+------------------------------------- Reporter: edsko | Owner: thomie Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D746 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5449b25d02cca0c4ae706c9152f5f2c6107fe711/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5449b25d02cca0c4ae706c9152f5f2c6107fe711" Clarify meaning of the RTS `taskCount` variable In #9261, there was some confusion about the meaning of the taskCount stats variable in the rts. It turns out that taskCount is not decremented when a worker task is stopped (i.e. from workerTaskStop), but only when freeMyTask is called, which frees the task bound to the current thread. So taskCount is the current number of bound tasks + the total number of worker tasks. This makes the calculation of the current number of bound tasks in rts/Stats.c correct _as is_. [skip ci] Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D746 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 11:23:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 11:23:28 -0000 Subject: [GHC] #9261: -S prints incorrect number of bound tasks In-Reply-To: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> References: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> Message-ID: <059.f1dcdc32f7c6e919d44462c45909bd3b@haskell.org> #9261: -S prints incorrect number of bound tasks -------------------------------------+------------------------------------- Reporter: edsko | Owner: thomie Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8124 | Blocking: | Differential Revisions: Phab:D746 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * related: => #8124 Comment: The code seems correct to me, so I'm closing this. But if you think you really do see weird numbers reported, of course reopen. Note that if your code doesn't explicitly call `hs_thread_done` (#8124), the number of bound tasks never decreases. So `taskCount` would be the sum of the total number of bound tasks and the total number of worker tasks ever created in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 16:22:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 16:22:33 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.08fdd9417abcfafe77049cb0860a613d@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"5119e097b5cc08d1e6e94529d8c6d7c654a28829/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5119e097b5cc08d1e6e94529d8c6d7c654a28829" Test case for #10176 originally provided by Neil Mitchell. Despite what he observed, I can observe the bug even with all in one module. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 16:22:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 16:22:33 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.8d8c530bab1a0aace26dc74e71de0cea@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"b4efac59ef5aac74d382d1fd57652982edddbe75/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b4efac59ef5aac74d382d1fd57652982edddbe75" Trim Call Arity to not accidentially invalidate a strictness signature with a Diverges result info. This seems to fix #10176. Differential Revision: https://phabricator.haskell.org/D747 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 16:24:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 16:24:35 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.d23aed834a31e7dd07dbc50b999fe698@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => merge Comment: Pushed. hvr, you said you wanted this to be in 7.10, so marking it as merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 16:51:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 16:51:18 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.17d43c22b4b03111b4822cdd3b058a08@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => infoneeded Comment: Sure enough, it trips over this {{{ *** Core Lint errors : in result of Simplifier *** libraries/base/Data/Void.hs:66:8: Warning: [in body of lambda with binder a_a2y6 :: Void] No alternatives for a case scrutinee not known to diverge for sure: a_a2y6 }}} Simon, what would you prefer: Should `exprIsBottom e` hold for all `e` where the type is a data type with no constructors, or should the lint check take that into account? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 17:05:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 17:05:58 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.90d5a9512142a0a7f476fcbcb464a952@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: I've merged (& validated) the fix & test (but not the linter-change) to ghc-7.10 via 011f691333aff2833acc900ee3911885e488cf1b & 7e1758a9cf86c28440834d3e3d44737186e5ca5f respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 17:41:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 17:41:34 -0000 Subject: [GHC] #10176: Invalid core generated with GHC 7.10 RC3 In-Reply-To: <051.8795776bc89448b822d3578207722ec2@haskell.org> References: <051.8795776bc89448b822d3578207722ec2@haskell.org> Message-ID: <066.48ff7b46ee7a202441d5337b28f0278c@haskell.org> #10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Thanks. Note that the test case is quite useless without the lint (but doesn?t hurt either so just leave it like it is). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 17:53:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 17:53:24 -0000 Subject: [GHC] #10181: Lint check: arity invariant In-Reply-To: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> References: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> Message-ID: <061.24ae8b182991d9ef32bb4581a2b35667@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => infoneeded Comment: GHC compiles with this lint check, but not the test suite: The invariant `idArity <= typeArity` fails to hold in the situation of #8743: {{{ T8743.hs-boot:3:10: Warning: [RHS of $fxToRowMaybe :: forall a_ani. ToRow (Maybe a_ani)] idArity 1 exceeds typeArity 0: $fxToRowMaybe }}} Here `ToRow` is a one-member class that is also imported with a self- source-import {{{ module T8743 where import {-# SOURCE #-} T8743 () class ToRow a where toRow :: a -> [()] instance ToRow (Maybe a) where toRow Nothing = [()] toRow (Just _) = [()] }}} So presumably due to the SOURCE import, `typeArity` is unable to look through the newtype `ToRow`. Maybe it is better done as a lint warning, and not a lint error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 19:10:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 19:10:50 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.b001bbfe632ef22ef48624084e4bb7af@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Ok, added it to the linter for now; whether `exprIsBottom` should be extended is a different question. Next linter error when compiling GHC: It complains about this code: {{{ *** Core Lint errors : in result of Simplifier *** : Warning: In a case alternative: (False) No alternatives for a case scrutinee not known to diverge for sure: \ (@ a_agBy) -> lvl_smAM @ a_agBy ds3_alsA [...] case \ (@ a_agBy) -> lvl_smAM @ a_agBy ds3_alsA of _ [Occ=Dead] { }}} So there is a lambda under the case, but it is a type lambda. Bogus or not? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 19:16:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 19:16:57 -0000 Subject: [GHC] #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) In-Reply-To: <049.f0ae68dfd7e58122643bba7078f24559@haskell.org> References: <049.f0ae68dfd7e58122643bba7078f24559@haskell.org> Message-ID: <064.2740f2065b0770e028cda7549681e8ad@haskell.org> #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) -------------------------------+------------------------------------------- Reporter: jaseemabid | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Comment (by jaseemabid): I hit a similar error and it might be related. Source: https://github.com/jaseemabid/functorrent (Its a different project, but similar build and libraries) Version: ac4100f4f9ed09fcba4c482f3c245fc5837324b1 $ cabal test Preprocessing library functorrent-0.1.0.0... In-place registering functorrent-0.1.0.0... Preprocessing test suite 'lisper-test' for functorrent-0.1.0.0... Linking dist/build/lisper-test/lisper-test ... Undefined symbols for architecture x86_64: "_functorrentzm0zi1zi0zi0_FuncTorrentziUtils_zdwsplitN_closure", referenced from: _S7Tj_srt in libHSfunctorrent-0.1.0.0.a(Peer.o) _SeM6_srt in libHSfunctorrent-0.1.0.0.a(Tracker.o) "_functorrentzm0zi1zi0zi0_FuncTorrentziUtils_zdwsplitN_info", referenced from: _c8uZ_info in libHSfunctorrent-0.1.0.0.a(Peer.o) _c8yP_info in libHSfunctorrent-0.1.0.0.a(Peer.o) _functorrentzm0zi1zi0zi0_FuncTorrentziTracker_zdwurlEncodeHash_info in libHSfunctorrent-0.1.0.0.a(Tracker.o) _cfnK_info in libHSfunctorrent-0.1.0.0.a(Tracker.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Public build: https://travis- ci.org/jaseemabid/functorrent/builds/55397669 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 19:18:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 19:18:15 -0000 Subject: [GHC] #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) In-Reply-To: <049.f0ae68dfd7e58122643bba7078f24559@haskell.org> References: <049.f0ae68dfd7e58122643bba7078f24559@haskell.org> Message-ID: <064.168c4794e5ee0546f77dd492493577b5@haskell.org> #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) -------------------------------+------------------------------------------- Reporter: jaseemabid | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Comment (by jaseemabid): The same can be compiled with Emacs' haskel-mode and the it runs fine. Its an issue only when invoked through `cabal test` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 22:52:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 22:52:53 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.dcbbcd18710ef6c0a3efd166b9a3aa91@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9839 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carlostome): Maybe we should change {{{rts/RtsFlags.c}}} to make use of because now the option parser is a bit scaring. I think I can do it myself. Any suggestions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 23:21:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 23:21:03 -0000 Subject: [GHC] #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) In-Reply-To: <049.f0ae68dfd7e58122643bba7078f24559@haskell.org> References: <049.f0ae68dfd7e58122643bba7078f24559@haskell.org> Message-ID: <064.435232857d53cf09755ffd7b4e54eb56@haskell.org> #10151: Compilation failed on mac, ghc: panic! (the 'impossible' happened) -------------------------------+------------------------------------------- Reporter: jaseemabid | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Changes (by mpickering): * status: infoneeded => closed * resolution: => invalid Comment: He was missing a module in his cabal file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 23:51:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 23:51:31 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.1d3487e180364a4a64d8dbdfafa84353@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9839 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Make sure that whatever you do also works, and behaves the same, on Windows, Mac, Solaris, FreeBSD. At least in theory. Is getopt.h posix only, or is avaible the way ghc is built on Windows (I don't know). configure.ac would also need updating? I noticed Python keeps their own copy of getopt, would that be an option? From https://hg.python.org/cpython/rev/a826a46bae54: "Move our own getopt() implementation to _PyOS_GetOpt(), and use it regardless of whether the system getopt() does what we want. This avoids the hassle with prototypes and externs, and the check to see if the system getopt() does what we want." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 22 23:57:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Mar 2015 23:57:33 -0000 Subject: [GHC] #9839: RTS options parser silently accepts invalid flags In-Reply-To: <049.1ac180907787acdf75c140998b5b4263@haskell.org> References: <049.1ac180907787acdf75c140998b5b4263@haskell.org> Message-ID: <064.fc6bb250442cf255be1d5af095a7bc54@haskell.org> #9839: RTS options parser silently accepts invalid flags -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: carlostome Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #4243 | Differential Revisions: Phab:D748 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"a20cc3d00c4ca0753fcdcb16199f173b3af44fe4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a20cc3d00c4ca0753fcdcb16199f173b3af44fe4" rts: check arguments to flags that don't have any There were some flags of the RTS that when given an argument (which they don't have) were not firing an error. e.g -Targument when the flag -T has no argument. Now this is an error and affects the following flags: -B -w -T -Z -P -Pa -c -t Signed-off-by: Carlos Tom? Reviewed By: austin, thomie, hvr Differential Revision: https://phabricator.haskell.org/D748 GHC Trac Issues: #9839 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 00:04:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 00:04:04 -0000 Subject: [GHC] #9839: RTS options parser silently accepts invalid flags In-Reply-To: <049.1ac180907787acdf75c140998b5b4263@haskell.org> References: <049.1ac180907787acdf75c140998b5b4263@haskell.org> Message-ID: <064.170b84f1f4d729ba7840339fdfe5d4c9@haskell.org> #9839: RTS options parser silently accepts invalid flags -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: carlostome Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #4243 | Differential Revisions: Phab:D748 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Thanks Carlos! The only thing not handled by this patch is checking that arguments that are supposed to be numeric, are actually numeric. Currently `atof` is called on them, which accepts pretty much anything. Maybe a fix for this can be part of #4243. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 03:30:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 03:30:31 -0000 Subject: [GHC] #7198: New codegen more than doubles compile time of T3294 In-Reply-To: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> References: <047.96b5f0effd7d95ff044f855e6d48f3db@haskell.org> Message-ID: <062.a157d246c7d3ea969604a61e8023ce55@haskell.org> #7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Related Tickets: #4258 | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * failure: None/Unknown => Compile-time performance bug * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 03:35:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 03:35:40 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.5622033e38627c4ef1bee382b54373a9@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 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 Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 03:40:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 03:40:24 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.7e77338805c31ad6d504ba16c8d9c893@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9839 | Blocking: 7535 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * blocking: => 7535 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 03:58:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 03:58:40 -0000 Subject: [GHC] #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! In-Reply-To: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> References: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> Message-ID: <061.ad3d0966ada7feeb40df4ea05fc5eff7@haskell.org> #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! ---------------------------------+----------------------------------------- Reporter: jamshid | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by thomie): I'm sorry we can't really help you with this. Maybe try a different version of GHC or cabal. Change the `jobs` setting in your ~/.cabal/config file perhaps. Ask on stackoverflow or #haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 04:08:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 04:08:31 -0000 Subject: [GHC] #9048: armel: evacuate(static): strange closure type 0 In-Reply-To: <046.ccacb8854bad97b5f58adb6faa140591@haskell.org> References: <046.ccacb8854bad97b5f58adb6faa140591@haskell.org> Message-ID: <061.e5c84db49bfe1aa7c19ccf3c11b90bdd@haskell.org> #9048: armel: evacuate(static): strange closure type 0 ----------------------------------------+-------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+-------------------------------- Changes (by thomie): * failure: None/Unknown => Building GHC failed * architecture: Unknown/Multiple => arm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 04:23:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 04:23:52 -0000 Subject: [GHC] #10001: GHC crash trying to build a project within Nix-shell In-Reply-To: <047.a911662f59d5386fa0d95515f4c6d044@haskell.org> References: <047.a911662f59d5386fa0d95515f4c6d044@haskell.org> Message-ID: <062.05273597d4504db36c112ebd4649c526@haskell.org> #10001: GHC crash trying to build a project within Nix-shell -------------------------------------+------------------------------------- Reporter: wolftune | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: 9825 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Does your example also fail outside a Nix-shell? I don't know what a Nix- shell is, so I can't reproduce this. Could this be related to #10131 ("improve error message for build on noexec-mounted device") -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 04:50:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 04:50:35 -0000 Subject: [GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel In-Reply-To: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> References: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> Message-ID: <059.ebfc5f4147fdc16e2aa9288da0da22f1@haskell.org> #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Running the above `ghc-stage2` command under gdb and grabbing the backtrace results in: {{{ Program received signal SIGSEGV, Segmentation fault. 0x00290108d000a388 in ?? () (gdb) bt X0 0x00290108d000a388 in ?? () X1 0x0000000002b7b940 in StgRun (f=, f at entry=0x2b8a788 , basereg=) at rts/StgCRun.c:81 X2 0x0000000002b7e114 in schedule (initialCapability=initialCapability at entry=0x3975a40 , task=task at entry=0x39a7470) at rts/Schedule.c:463 X3 0x0000000002b7ef5c in scheduleWaitThread (tso=0x7fb7c0b388, ret=ret at entry=0x0, pcap=pcap at entry=0x7ffffff4d8) at rts/Schedule.c:2380 X4 0x0000000002b75698 in rts_evalLazyIO (cap=cap at entry=0x7ffffff4d8, p=p at entry=0x2f79bc0 , ret=ret at entry=0x0) at rts/RtsAPI.c:500 X5 0x0000000002b80428 in hs_main (argc=49, argv=0x7ffffff688, main_closure=0x2f79bc0 , rts_config=...) at rts/RtsMain.c:64 X6 0x000000000042ea9c in main () }}} which suggests something going awry in `StgRun`. In addition, running the above command under gdb showed that 3 extra threads were being started whereas, if `ghc-stage2` is replaced with `ghc- stage1` and run, only a single thread (the initial host thread) is started. This on the other hand suggests a threading problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 04:52:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 04:52:51 -0000 Subject: [GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel In-Reply-To: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> References: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> Message-ID: <059.86988209e89cf437c47c1f041f1c3940@haskell.org> #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Compiling with `BuildFlavour` of `quick-llvm` but with the addition of `DYNAMIC_BY_DEFAULT` and `DYNAMIC_GHC_PROGRAMS` being set to `NO` so this is not a problem with the dynamic linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 04:55:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 04:55:25 -0000 Subject: [GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals In-Reply-To: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> References: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> Message-ID: <060.7a8e7d551a31bb3cec8e1e6e86e96f07@haskell.org> #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 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 Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * priority: normal => low Comment: We should probably follow the report here. Shouldn't be too difficult. The file to change is `compiler/parser/Lexer.x`. Look at the functions `lex_string` and `lex_stringgap`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 04:55:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 04:55:49 -0000 Subject: [GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals In-Reply-To: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> References: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> Message-ID: <060.14ffd3d6777c51fab34072910bb2c3f9@haskell.org> #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Parser) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Parser) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 05:09:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 05:09:01 -0000 Subject: [GHC] #9917: ddump-llvm runs opt/llc even when -fllvm isnt set In-Reply-To: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> References: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> Message-ID: <060.eddfb6cc2eb9a05f948e3ff8fb5aa203@haskell.org> #9917: ddump-llvm runs opt/llc even when -fllvm isnt set -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => low * component: Compiler => Documentation Comment: `-ddump-llvm` currently implies `-fllvm`, as do `-keep-llvm-file` and `-keep-llvm-files`. This could be mentioned in the user's guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 05:18:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 05:18:06 -0000 Subject: [GHC] #8078: Core lint failure for profiled code In-Reply-To: <045.ae38de516bdfa42d9f62952660a2ed9d@haskell.org> References: <045.ae38de516bdfa42d9f62952660a2ed9d@haskell.org> Message-ID: <060.7909f6e2a63867f19d7cf8714f8f53a6@haskell.org> #8078: Core lint failure for profiled code -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T4492 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: T4492 works for me in the `profasm` way, so this must have been fixed at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 05:24:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 05:24:59 -0000 Subject: [GHC] #8487: Debugger confuses variables In-Reply-To: <044.aa4eb9fcbb6c77f9d0eddc9c941c5acb@haskell.org> References: <044.aa4eb9fcbb6c77f9d0eddc9c941c5acb@haskell.org> Message-ID: <059.bfad8b3619e2612e5fe95ca028db572d@haskell.org> #8487: Debugger confuses variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 05:29:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 05:29:26 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.e0893a8c34c2981241194e34496e883f@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -------------------------------+----------------------------------------- Reporter: teuffy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Replying to [comment:13 teuffy]: > Bug is gone within ghci after the installation of ghc 7.8.1. Many thanks for your help and support Please reopen this ticket if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 05:41:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 05:41:16 -0000 Subject: [GHC] #9849: GHC readme.md seems out of date In-Reply-To: <045.1648ba45c23de1341394f39c1acb1358@haskell.org> References: <045.1648ba45c23de1341394f39c1acb1358@haskell.org> Message-ID: <060.ca740f8ea4250720125742395c34260c@haskell.org> #9849: GHC readme.md seems out of date -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9861 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9861 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 05:44:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 05:44:32 -0000 Subject: [GHC] #7098: GHC 7.4.1 reports an internal error and core dumps while using DPH In-Reply-To: <047.4a68704e94a80fef0c8983028b370c53@haskell.org> References: <047.4a68704e94a80fef0c8983028b370c53@haskell.org> Message-ID: <062.d2e60f11f8a866c663a617f4d545d605@haskell.org> #7098: GHC 7.4.1 reports an internal error and core dumps while using DPH -------------------------------------+------------------------------------- Reporter: Prasanna | Owner: benl Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel | Version: 7.4.1 Haskell | Keywords: DPH Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 7330 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Data Parallel Haskell * milestone: 7.12.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 06:03:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 06:03:12 -0000 Subject: [GHC] #10146: Clang CPP adds extra newline character In-Reply-To: <049.7d16de83828bec74f9ab166d6dbd4393@haskell.org> References: <049.7d16de83828bec74f9ab166d6dbd4393@haskell.org> Message-ID: <064.846684a442e009455d7dd6eb9e89a228@haskell.org> #10146: Clang CPP adds extra newline character -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => invalid Comment: Replying to [comment:3 mpickering]: > I think you're right that it's not a GHC issue and there's nothing that would be sensible to change in GHC. Unless you change your mind, lets close this then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 06:10:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 06:10:06 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example In-Reply-To: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> References: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> Message-ID: <057.b84a9327f2473072e445abcb4844287b@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 06:33:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 06:33:02 -0000 Subject: [GHC] #9194: Remove magic parsing of (~) In-Reply-To: <047.22060322fda4067ab1167cb54140f19a@haskell.org> References: <047.22060322fda4067ab1167cb54140f19a@haskell.org> Message-ID: <062.5f89d2f4c92a49715682d396b0808319@haskell.org> #9194: Remove magic parsing of (~) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Parser) * related: => #10059 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 08:59:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 08:59:07 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.f5313c1aa3a421e6ee8159211da620aa@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > Simon, what would you prefer: Should `exprIsBottom e` hold for all `e` where the type is a data type with no constructors, or should the lint check take that into account? Very interesting. * What program gives rise to `case (x::Void) of {}`? * Yes, I think there is a case for making `exprIsBottom` hold for data types with no constructors; after all, such an expression is bound to diverge. * A slightly less pervasive change would to to say that an empty `case` is ok on a data type that has an empty set of constructors. Less pervasive in the sense that it affects this Lint check only, whereas the `exprIsBottom` fix would have broader implications: good ones, I think, but also rare. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:00:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:00:31 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.ef9b8c3dd6f587092c8695c7c9b72aa9@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:2 nomeata]: > So there is a lambda under the case, but it is a type lambda. Bogus or not? Ha! There's a missing case in `exprIsBottom`: {{{ exprIsBottom (Lam v e) | isTyVar v = exprIsBottom e }}} Well spotted. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:16:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:16:15 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.9271b1ae9a3dd13a3ef196c9aac4998f@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Hi, Replying to [comment:3 simonpj]: > Very interesting. > * What program gives rise to `case (x::Void) of {}`? Precisely that program :-) See `Data.Void`: {{{ absurd :: Void -> a absurd a = case a of {} }}} > * Yes, I think there is a case for making `exprIsBottom` hold for data types with no constructors; after all, such an expression is bound to diverge. > * A slightly less pervasive change would to to say that an empty `case` is ok on a data type that has an empty set of constructors. Less pervasive in the sense that it affects this Lint check only, whereas the `exprIsBottom` fix would have broader implications: good ones, I think, but also rare. I?ll do that first, and afterwards look into moving the no-constructor- test into `exprIsBottom`. Replying to [comment:4 simonpj]: > Replying to [comment:2 nomeata]: > > So there is a lambda under the case, but it is a type lambda. Bogus or not? > > Ha! There's a missing case in `exprIsBottom`: > {{{ > exprIsBottom (Lam v e) | isTyVar v = exprIsBottom e > }}} > Well spotted. I?ll add that and see if the linter is happy then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:17:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:17:19 -0000 Subject: [GHC] #10181: Lint check: arity invariant In-Reply-To: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> References: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> Message-ID: <061.60485dc73a9e771487d5cc730f24574f@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This looks like a bug in the SOURCE-import mechanism to me. I think the same bug happens here: {{{ bash$ ghc -c T8743.hs-boot bash$ ghc -c T8743.hs ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: main:T8743.$fxToRowMaybe{v r2J} [(r2L, Class ?main:T8743.ToRow{tc r2L}?), (r2M, Data constructor ?main:T8743.D:ToRow{d r2M}?), (r2P, Identifier ?main:T8743.D:ToRow{v r2P}?), (roB, Identifier ?main:T8743.toRow{v roB}?), (rqT, Coercion axiom ?main:T8743.NTCo:ToRow{tc rqT}?)] }}} Bother. Well I suppose it would be good to open a separate ticket about that. But I'll stick to my guns about `idArity <= typeArity` for now. See `Note [exprArity invariant]` in `CoreArity`. Did you find any other cases? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:17:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:17:55 -0000 Subject: [GHC] #10181: Lint check: arity invariant In-Reply-To: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> References: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> Message-ID: <061.cbcdfe48a3eacb0a7e6a6b76222e6065@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): branch `wip/T10181`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:19:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:19:25 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.816135ec31f5103b1ecf9db98e674993@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): BTW, there should be no need to check ''both'' `exprIsHNF` ''and'' `exprIsBottom`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:22:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:22:03 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.68fd4ca0b2378dc144a12733070f056e@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): branch `wip/T10180` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:22:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:22:04 -0000 Subject: [GHC] #10181: Lint check: arity invariant In-Reply-To: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> References: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> Message-ID: <061.8d36e53f21e3534d5a9428f6bd2f6cb9@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Hi, Replying to [comment:2 simonpj]: > This looks like a bug in the SOURCE-import mechanism to me. > [?] > Bother. Well I suppose it would be good to open a separate ticket about that. I would, but I?m not able to summarize what precisely is wrong here, and how to phrase the ticket. > But I'll stick to my guns about `idArity <= typeArity` for now. See `Note [exprArity invariant]` in `CoreArity`. > > Did you find any other cases? Not yet, as I stumbled over this while building GHC. I can make it a lint warning for now and see what else comes up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:38:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:38:06 -0000 Subject: [GHC] #4150: CPP+QuasiQuotes confuses compilation errors' line numbers In-Reply-To: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> References: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> Message-ID: <061.091b8b9e2292ae9f01c39c671d79604e@haskell.org> #4150: CPP+QuasiQuotes confuses compilation errors' line numbers -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | quasiquotation/T4150 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: low => normal Comment: There is a test already actually: `quasiquotation/T4150`. It is currently marked as expect_broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:42:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:42:29 -0000 Subject: [GHC] #4150: CPP+QuasiQuotes confuses compilation errors' line numbers In-Reply-To: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> References: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> Message-ID: <061.1aafd6b763c18f8962ec1b10e4c0e1ed@haskell.org> #4150: CPP+QuasiQuotes confuses compilation errors' line numbers -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | quasiquotation/T4150 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"f72074ec85edd06867587698be4f3db48d0658d0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f72074ec85edd06867587698be4f3db48d0658d0" Fix quasiquotation test (#4150) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 09:59:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 09:59:18 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.22d1f765eefb1176e04e44ec07e7382c@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): There is no end of reasons why something diverges: {{{ =====> T2431(normal) 339 of 4438 [0, 0, 0] cd ./deSugar/should_compile && "/home/jojo/build/haskell/ghc- validate/inplace/bin/ghc-stage2" -c T2431.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -ddump-simpl -dsuppress-uniques > T2431.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Simplifier *** T2431.hs:8:8: Warning: [in body of lambda with binder x :: Int :~: Bool] No alternatives for a case scrutinee not known to diverge for sure: x *** Offending Program *** absurd :: forall a. Int :~: Bool -> a [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] absurd = \ (@ a) (x :: Int :~: Bool) -> case x of _ [Occ=Dead] { } *** End of Offense *** }}} I?m beginning to wonder if the lint rule is a good idea. After all, by trying to add such a rule we are saying ?definite divergence must be obvious?, and hence we would be precluding the compiler to derive and use definite divergence that is non-obvious, or that was obvious at one point in the pipeline, but isn?t any more later when the linter runs. Here is an example of non-trivially always empty types: `Void` wrapped deeply in some strict data type. Or even `Void` as the result of a type function wrapped deeply in some strict data type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 10:09:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 10:09:38 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.b3d37a97743a09eb536e97afe9095f60@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Well that's why I said (somewhere) that I wasn't certain this would work, but it would be interesting to know. The point is: to make the empty case, GHC '''knew''' at some point that the expression must diverge. So how has it lost that knowledge? I think that in this case it's a use of `dataConCantMatch`. So maybe we can beef up `isEmptyTy` to use that information? (And ultimately perhaps beef up `exprIsBottom`.) My point is, this is a useful quest. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 10:22:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 10:22:21 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.43d97398724deb0a7a8381bbb6128c70@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I?ll be happy to pursue this course and see how far it will take us, but my gut feeling is that this will never be complete and even if GHC+the test suite go through, someone will be able to figure out how to make the linter fail erroneously. Making the check use `dataConCannotMatch` now, but it uses `Unify.typesCantMatch` which does not even look through newtypes (yet), so this will only get us so far... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 11:03:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 11:03:33 -0000 Subject: [GHC] #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes In-Reply-To: <042.2351aa32b11f999d614978d597e46a77@haskell.org> References: <042.2351aa32b11f999d614978d597e46a77@haskell.org> Message-ID: <057.d4e939a5ab9b0a1bf1b6cbd71ba70e3c@haskell.org> #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D736 -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * differential: => Phab:D736 * resolution: fixed => * version: 7.10.1-rc2 => 7.10.1-rc3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 11:04:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 11:04:53 -0000 Subject: [GHC] #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes In-Reply-To: <042.2351aa32b11f999d614978d597e46a77@haskell.org> References: <042.2351aa32b11f999d614978d597e46a77@haskell.org> Message-ID: <057.41f4f35c36465d7359374f73ba24257f@haskell.org> #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D736 -------------------------------------+------------------------------------- Comment (by thomie): Hijacking this ticket. Please don't forget https://phabricator.haskell.org/D736 "Rearrange order of the highlights so that breaking-change/non- experimental are first" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 11:06:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 11:06:37 -0000 Subject: [GHC] #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes In-Reply-To: <042.2351aa32b11f999d614978d597e46a77@haskell.org> References: <042.2351aa32b11f999d614978d597e46a77@haskell.org> Message-ID: <057.e40cb0be67191473ae2bc2e4a8c51f94@haskell.org> #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D736 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge Comment: Not really in HEAD, but ready for merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 11:24:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 11:24:35 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import Message-ID: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Try this (in `testsuite/tests/stranal/should_compile`) {{{ bash$ ghc -c T8743.hs-boot bash$ ghc -c T8743.hs ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: main:T8743.$fxToRowMaybe{v r2J} [(r2L, Class ?main:T8743.ToRow{tc r2L}?), (r2M, Data constructor ?main:T8743.D:ToRow{d r2M}?), (r2P, Identifier ?main:T8743.D:ToRow{v r2P}?), (roB, Identifier ?main:T8743.toRow{v roB}?), (rqT, Coercion axiom ?main:T8743.NTCo:ToRow{tc rqT}?)] }}} Something clearly wrong here. It think this happens with prettty much any version of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 11:25:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 11:25:11 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.1fc690093c13dd351667fb535e0d9deb@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Try this (in `testsuite/tests/stranal/should_compile`) > {{{ > bash$ ghc -c T8743.hs-boot > bash$ ghc -c T8743.hs > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-unknown-linux): > tcIfaceGlobal (local): not found: > main:T8743.$fxToRowMaybe{v r2J} > [(r2L, Class ?main:T8743.ToRow{tc r2L}?), > (r2M, Data constructor ?main:T8743.D:ToRow{d r2M}?), > (r2P, Identifier ?main:T8743.D:ToRow{v r2P}?), > (roB, Identifier ?main:T8743.toRow{v roB}?), > (rqT, Coercion axiom ?main:T8743.NTCo:ToRow{tc rqT}?)] > }}} > Something clearly wrong here. It think this happens with prettty much any > version of GHC. New description: Try this (in `testsuite/tests/stranal/should_compile`) {{{ bash$ ghc -c T8743.hs-boot bash$ ghc -c T8743.hs ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: main:T8743.$fxToRowMaybe{v r2J} [(r2L, Class ?main:T8743.ToRow{tc r2L}?), (r2M, Data constructor ?main:T8743.D:ToRow{d r2M}?), (r2P, Identifier ?main:T8743.D:ToRow{v r2P}?), (roB, Identifier ?main:T8743.toRow{v roB}?), (rqT, Coercion axiom ?main:T8743.NTCo:ToRow{tc rqT}?)] }}} Something clearly wrong here. It think this happens with prettty much any version of GHC. I found this when poking about in #10181. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 11:26:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 11:26:50 -0000 Subject: [GHC] #10179: Kinds missing from types in ghci In-Reply-To: <042.49d0257de6eb7718086e9479b7e7019f@haskell.org> References: <042.49d0257de6eb7718086e9479b7e7019f@haskell.org> Message-ID: <057.42b968a697d7ccab8a33204195d39662@haskell.org> #10179: Kinds missing from types in ghci -------------------------------------+------------------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE PolyKinds #-} > > data family F (a:: k) > > foo :: F (m :: [()]) -> a > foo = undefined > bar :: F (m :: [[()]]) -> a > bar = undefined > > according to GHCi, both foo and bar have type F m -> a but [foo, bar] > fails New description: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} data family F (a:: k) foo :: F (m :: [()]) -> a foo = undefined bar :: F (m :: [[()]]) -> a bar = undefined }}} according to GHCi, both `foo` and `bar` have type `F m -> a` but `[foo, bar]` fails -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 11:35:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 11:35:17 -0000 Subject: [GHC] #10181: Lint check: arity invariant In-Reply-To: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> References: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> Message-ID: <061.96b3bc9020a4b4fdc16fd965f4c00f00@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:4 nomeata]: > > Did you find any other cases? > > Not yet, as I stumbled over this while building GHC. I can make it a lint warning for now and see what else comes up. nevermind. That case was already in the test suite. So now, I did not find any other cases in GHC+Testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 11:41:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 11:41:39 -0000 Subject: [GHC] #10179: Kinds missing from types in ghci In-Reply-To: <042.49d0257de6eb7718086e9479b7e7019f@haskell.org> References: <042.49d0257de6eb7718086e9479b7e7019f@haskell.org> Message-ID: <057.87a680385dcc569cf7c3fa9662fd2fcd@haskell.org> #10179: Kinds missing from types in ghci -------------------------------------+------------------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Good point. The question is this: '''when pretty-printing a type, when and how should we display kind annotations?'''. Currenty in GHCi we by- default suppress foralls and kind annotations. (NB: by the time we get to "pretty print this type" we've lost touch with the original source-language type signature, and in any case the same rules should apply for inferred types.) For example, this is what happens currently (without `-fprint-explicit- foralls` and `-fprint-explicit-kinds`): {{{ Type Display ------------------------------------------------------------------------------- 1. f :: forall (a::*). a->a f :: a->a 2. f :: forall (m::*->*) (a::*). m a -> a f :: m a -> a 3. f :: forall (k::BOX) (m::k->*) (a::k). m a -> m a f :: m a -> m a ??? 4. f :: forall (m::*->*) (a::*). m a -> m a f :: m a -> m a ??? }}} Note that * In (2) the kinds are forced by the rest of the type `m a -> a` * In (3), assuming `-XPolyKinds` the type on the left is the most kind- polymorphic type compatible with the type on the right. * In (4) the kind polymoprhism has been squashed out, as it has in the ticket description. The trouble is that (3) and (4) are displayed the same, even though they are different. It's hard to even say exactly what we want here! Perhaps something like "print the kind-attributed foralls explicitly, unless the kinds are implied by the most-kind-polymorphic reading of the signature"; but that's quite complicated. Ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 11:43:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 11:43:11 -0000 Subject: [GHC] #10181: Lint check: arity invariant In-Reply-To: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> References: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> Message-ID: <061.c55518ff3de30e6cdbdb3b1dd251722c@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK good. Well maybe add it, and mark `T8743` as expect-broken on #10182. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 12:19:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 12:19:15 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.ceaab11b365daf6e769fb6f181dfcb60@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: carlostome Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9839 | Blocking: 7535 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by carlostome): * owner: => carlostome -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 12:43:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 12:43:28 -0000 Subject: [GHC] #10181: Lint check: arity invariant In-Reply-To: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> References: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> Message-ID: <061.e277318b91911a76c665d617a8bbf1dc@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:751 -------------------------------------+------------------------------------- Changes (by nomeata): * status: infoneeded => patch * differential: => Phab:751 Comment: Replying to [comment:6 simonpj]: > OK good. Well maybe add it, and mark `T8743` as expect-broken on #10182. Good idea, that validates. See Phab:D751. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 12:57:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 12:57:22 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.67df41c28f5bf4afd509d52b44032d25@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"0f03a843e7e740218f3ce3853f80de99b0ed6236/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0f03a843e7e740218f3ce3853f80de99b0ed6236" Make testsuite driver Python 2.6 compatible again Another bug in the #10164 series. Only Python 2.7 and up allow you to omit the positional argument specifiers in format strings. Test Plan: this fixes the Solaris builders Reviewed By: kgardas Differential Revision: https://phabricator.haskell.org/D750 GHC Trac Issues: #10164 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 12:57:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 12:57:37 -0000 Subject: [GHC] #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! In-Reply-To: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> References: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> Message-ID: <061.abb06dd5ed4fe5ab320a445cdbba04fb@haskell.org> #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! ---------------------------------+----------------------------------------- Reporter: jamshid | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by goldfire): I wonder if we can at least get some more information before throwing our hands up in despair. Thanks for the detailed post and addressing some obvious responses (e.g. "That's clearly bogus hardware!") For a given package, does `cabal build` ''always'' trigger the reboot? Or is it just some of the time? (I take it that the odds increase with the size of the package.) Cabal folks: is there a way to get `cabal build` to spit out exactly what it's doing? I don't see a verbosity option in `cabal help build`. My guess, from the description above, is that some cabal behavior is perhaps triggering some latent bug in the GHC runtime. If we could get a record of what cabal is doing -- and find a way to spit a log to some file '''without buffering''' -- we might be able to learn more. But I'm afraid that's where my personal expertise runs out. Any advice from others? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 13:01:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 13:01:09 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.7e9abfe6dafdebaf193ba2571826b627@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 13:02:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 13:02:57 -0000 Subject: [GHC] #9194: Remove magic parsing of (~) In-Reply-To: <047.22060322fda4067ab1167cb54140f19a@haskell.org> References: <047.22060322fda4067ab1167cb54140f19a@haskell.org> Message-ID: <062.a02d5ba9381e7b3bec265bfb285d673a@haskell.org> #9194: Remove magic parsing of (~) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Keywords: Resolution: duplicate | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10056 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate * related: #10059 => #10059, #10056 Comment: I'm closing this in favor of #10056, which is essentially the same issue and has better comments on the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 13:03:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 13:03:21 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.1ba62fe0b0236a6808a380183cabd4ce@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10059 | -------------------------------------+------------------------------------- Comment (by goldfire): See also brief commentary on #9194, which is a dup of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 13:04:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 13:04:37 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.4b591c12e1180717aa9d8b9b67198b2b@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: merge Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge Comment: austin: sorry to bother you with this last-minute patch. It would not be the end of the world if it doesn't make it, as it would just require python 2.7 to be installed to run the 7.10 testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 13:18:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 13:18:37 -0000 Subject: [GHC] #10179: Kinds missing from types in ghci In-Reply-To: <042.49d0257de6eb7718086e9479b7e7019f@haskell.org> References: <042.49d0257de6eb7718086e9479b7e7019f@haskell.org> Message-ID: <057.4b275d8b74eae4309c31afe1b184194a@haskell.org> #10179: Kinds missing from types in ghci -------------------------------------+------------------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I think the problem here is that GHC/the Haskell community, in general, is quite ambivalent about kind-polymorphism. My take on it all is that the power users want it. At the same time, we're afraid that it will scare people, and so we're a little embarrassed of those `k`s showing up to unsuspecting folks without deep experience with type theory. So, we hide the kinds behind `-fprint-explicit-kinds`. I don't think we'll resolve this tension anytime soon, as it's there for a good reason: we want both power and comprehensibility. But it's hard to have both, of course. So, here's a solution: do (broadly) what Idris does. (I don't have Idris to hand, so don't take the analogy too literally.) When a type prints out, suppress kinds. BUT, have some interactive way of requesting more information, say by clicking on the type. I know this solution will take a lot of work, but I think that work will be very worthwhile down the road. See, for example, #10073. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 13:29:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 13:29:40 -0000 Subject: [GHC] #10183: Warning for redundant constraints: interaction with pattern matching Message-ID: <046.02647e82b4059f07aa24c7e2e29b1e1f@haskell.org> #10183: Warning for redundant constraints: interaction with pattern matching -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Herbert gives this example: {{{ {-# LANGUAGE GADTs, DataKinds, TypeOperators, UnicodeSyntax #-} import GHC.TypeLits data List l t where Nil ? List 0 t (:-) ? t ? List l t ? List (l+1) t head' ? (1<=l) ? List l t ? t head' (x :- _) = x }}} We get the warning {{{ typelits1.hs:9:9: Warning: Redundant constraint: 1 <= l In the type signature for: head' ? (1 <= l) ? List l t ? t }}} But of course the warning is not redundant if we want to exclude the `(head' Nil)` case. Here's an example that doesn't depend on `TypeLits`: {{{ data T a where TT :: T True TF :: T False f :: T True -> Bool f TT = True g :: (a ~ True) => T a -> Bool g TT = True }}} Here `f` compiles fine, but `g` warns about a redundant constraint! And indeed the evidence for `(a~True)` is not used in the code for `g`. But that evidence is used to prove that the un-matched pattern `(g TF)` is unreachable. I'm not sure how to fix this. Bother. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 13:30:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 13:30:09 -0000 Subject: [GHC] #10183: Warning for redundant constraints: interaction with pattern matching In-Reply-To: <046.02647e82b4059f07aa24c7e2e29b1e1f@haskell.org> References: <046.02647e82b4059f07aa24c7e2e29b1e1f@haskell.org> Message-ID: <061.eccfadae15a3632be57a3ebdb591ac33@haskell.org> #10183: Warning for redundant constraints: interaction with pattern matching -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Herbert gives this example: > {{{ > {-# LANGUAGE GADTs, DataKinds, TypeOperators, UnicodeSyntax #-} > > import GHC.TypeLits > > data List l t where > Nil ? List 0 t > (:-) ? t ? List l t ? List (l+1) t > > head' ? (1<=l) ? List l t ? t > head' (x :- _) = x > }}} > We get the warning > {{{ > typelits1.hs:9:9: Warning: > Redundant constraint: 1 <= l > In the type signature for: head' ? (1 <= l) ? List l t ? t > }}} > But of course the warning is not redundant if we want to exclude the > `(head' Nil)` case. > > Here's an example that doesn't depend on `TypeLits`: > {{{ > data T a where > TT :: T True > TF :: T False > > f :: T True -> Bool > f TT = True > > g :: (a ~ True) => T a -> Bool > g TT = True > }}} > Here `f` compiles fine, but `g` warns about a redundant constraint! And > indeed the evidence for `(a~True)` is not used in the code for `g`. But > that evidence is used to prove that the un-matched pattern `(g TF)` is > unreachable. > > I'm not sure how to fix this. Bother. New description: Herbert gives this example: {{{ {-# LANGUAGE GADTs, DataKinds, TypeOperators, UnicodeSyntax #-} import GHC.TypeLits data List l t where Nil ? List 0 t (:-) ? t ? List l t ? List (l+1) t head' ? (1<=l) ? List l t ? t head' (x :- _) = x }}} We get the warning {{{ typelits1.hs:9:9: Warning: Redundant constraint: 1 <= l In the type signature for: head' ? (1 <= l) ? List l t ? t }}} But of course the warning is not redundant if we want to exclude the `(head' Nil)` case. Here's an example that doesn't depend on `TypeLits`: {{{ data T a where TT :: T True TF :: T False f :: T True -> Bool f TT = True g :: (a ~ True) => T a -> Bool g TT = True }}} Here `f` compiles fine, but `g` warns about a redundant constraint, even though the two types are isomorphic! And indeed the evidence for `(a~True)` is not used in the code for `g`. But that evidence is used to prove that the un-matched pattern `(g TF)` is unreachable. I'm not sure how to fix this. Bother. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 13:35:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 13:35:36 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.55fc9a4c8a80695e19832d9b46a54231@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: infoneeded => new Comment: Ok, with the better `isEmptyTy`, it goes through, see Phab:D753. I?m not sure where best to put `isEmptyTy`. My first guess was `Types.hs`, but that would require extending `DataCon.hs-boot`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 14:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 14:00:27 -0000 Subject: [GHC] #10184: Coercible solver incomplete with recursive newtypes Message-ID: <047.7509967c1582acd23d4cd58fb93af3d5@haskell.org> #10184: Coercible solver incomplete with recursive newtypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.10.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following module fails to compile due to infinite recursion: {{{ import Data.Coerce newtype Bar a = Bar (Either a (Bar a)) newtype Age = MkAge Int x :: Bar Age x = coerce (Bar (Left (5 :: Int))) }}} It tries to coerce `Bar Int` to `Bar Age`. This is clearly doable, via tyconapp decomposition. But we don't find it. Before worrying too much about it, though, we'll wait for a real example. Do speak up if this problem is ruining your day! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 14:08:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 14:08:25 -0000 Subject: [GHC] #10183: Warning for redundant constraints: interaction with pattern matching In-Reply-To: <046.02647e82b4059f07aa24c7e2e29b1e1f@haskell.org> References: <046.02647e82b4059f07aa24c7e2e29b1e1f@haskell.org> Message-ID: <061.ebf5c619768591190bb384d8956a8a30@haskell.org> #10183: Warning for redundant constraints: interaction with pattern matching -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Does the fancy new pattern-match completeness checker help out here? Can GHC record somehow that a constraint is used when the completeness checker is thinking? In the meantime, does this mean the flag should be excluded from `-Wall` for 7.10? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 14:11:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 14:11:15 -0000 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found In-Reply-To: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> References: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> Message-ID: <062.0d944a49ffb79a10b50a4e0a6b743b95@haskell.org> #10158: Panic compiling singletons: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon, do you have a test case I could add to the testsuite as I land D653? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 14:25:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 14:25:44 -0000 Subject: [GHC] #10184: Coercible solver incomplete with recursive newtypes In-Reply-To: <047.7509967c1582acd23d4cd58fb93af3d5@haskell.org> References: <047.7509967c1582acd23d4cd58fb93af3d5@haskell.org> Message-ID: <062.e7c751cd70265a55e5f9ae764b7a54aa@haskell.org> #10184: Coercible solver incomplete with recursive newtypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * version: 7.10.1-rc3 => 7.11 Comment: Oops -- this is about 7.11, not 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 14:26:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 14:26:41 -0000 Subject: [GHC] #10185: Coercible solver incomplete with non-variable transitivity Message-ID: <047.c39f23321361d46a92df4fbbf1d28dbd@haskell.org> #10185: Coercible solver incomplete with non-variable transitivity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ import Data.Coerce import Data.Proxy foo :: (Coercible (a b) (c d), Coercible (c d) (e f)) => Proxy (c d) -> a b -> e f foo _ = coerce }}} I get an error, because GHC isn't smart enough to figure out transitivity in this case. It ''can'' do it with bare variables, but not variable applications. It's possible there's a way to do this, but we'll wait for someone to shout before investing effort. Do shout if this lack of functionality is ruining your day! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 15:02:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 15:02:04 -0000 Subject: [GHC] #8222: CTYPE pragma on newtype is ignored In-Reply-To: <043.24c148c2b068a302763a274e94396a01@haskell.org> References: <043.24c148c2b068a302763a274e94396a01@haskell.org> Message-ID: <058.28ed1a6aca1c384ce37240cd464afb8c@haskell.org> #8222: CTYPE pragma on newtype is ignored -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: akio: this problem seems fixed in 7.8 and later, can you confirm? I see the following line in the generated C file, which looks correct to me: {{{ void* ghczuwrapperZC0ZCmainZCMainZCCMSGzuDATA(struct cmsghdr* a1) {return CMSG_DATA(a1);} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 15:09:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 15:09:36 -0000 Subject: [GHC] #8556: Invalid constructor names are accepted in data declarations In-Reply-To: <044.fea5fff11e5ec10e023034a4e71b90cb@haskell.org> References: <044.fea5fff11e5ec10e023034a4e71b90cb@haskell.org> Message-ID: <059.83f5d49fdda13a28a95049a38d076845@haskell.org> #8556: Invalid constructor names are accepted in data declarations -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 15:16:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 15:16:38 -0000 Subject: [GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints In-Reply-To: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> References: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> Message-ID: <061.6ba5a9ca49c87576d051db08f5a089bd@haskell.org> #7897: MakeTypeRep fingerprints be proper, robust fingerprints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => ? Comment: Replying to [comment:3 simonpj]: > So the status quo,in which `TypeRep`s are essentially compared by name, is looking more attractive. No one is aruging for this change. So I propose to park it for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 15:28:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 15:28:45 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.3cb72c7fb4abc58fc9015324d09276ca@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darchon): I have another data-point for this performance bug: http://hackage.haskell.org/package/unbound-generics. Compiling the following example: https://github.com/lambdageek/unbound- generics/blob/master/examples/F.hs {{{ $ uname -a Darwin wlan022084.mobiel.utwente.nl 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 19:26:47 PST 2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64 ############################################################################# $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 $ ghc -O -c -Rghc-timing -fforce-recomp -Wnot F.hs <> ############################################################################# $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.0.20150323 $ ghc -O -c -Rghc-timing -fforce-recomp -Wnot F.hs <> }}} The interesting parts of running with -v2 are: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 $ ghc -O -c -Rghc-timing -fforce-recomp -Wnot -v2 F.hs [...] Result size of Simplifier = {terms: 2,583, types: 8,513, coercions: 1,371} *** Specialise: Result size of Specialise = {terms: 2,583, types: 8,513, coercions: 1,371} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 2,923, types: 9,081, coercions: 1,371} *** Float inwards: Result size of Float inwards = {terms: 2,923, types: 9,081, coercions: 1,371} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 6,490, types: 31,862, coercions: 17,447} [...] ############################################################################# $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.0.20150323 $ ghc -O -c -Rghc-timing -fforce-recomp -Wnot -v2 F.hs [...] Result size of Simplifier = {terms: 2,028, types: 5,759, coercions: 1,207} *** Specialise: Result size of Specialise = {terms: 11,945, types: 48,810, coercions: 9,282} *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 14,293, types: 68,412, coercions: 9,282} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 22,244, types: 103,329, coercions: 35,450} [...] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 15:37:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 15:37:08 -0000 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found In-Reply-To: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> References: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> Message-ID: <062.43784c1c7107b9decfd056d342c240ce@haskell.org> #10158: Panic compiling singletons: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): I do not. I just looked at the -ddump-ds trace from compiling singletons, noted the missing binding of a coercion, and traced it back to the flattener. With enough thought I might be able to construct a test case (as might you), but there are so many other things to do too Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 15:39:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 15:39:56 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.31da6a97545d78f297b98b8f30d58389@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Perhaps in `CoreUtils` which contains the other place that `dataConCannotMatch` is called, so it's a related chunk of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:26:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:26:26 -0000 Subject: [GHC] #8550: GHC builds recursive coerctions when using recursive type families In-Reply-To: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> References: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> Message-ID: <061.9c05cb732d106bf2209cb40bafa54b5d@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7788 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:26:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:26:27 -0000 Subject: [GHC] #10184: Coercible solver incomplete with recursive newtypes In-Reply-To: <047.7509967c1582acd23d4cd58fb93af3d5@haskell.org> References: <047.7509967c1582acd23d4cd58fb93af3d5@haskell.org> Message-ID: <062.23434d2f7be6a2293286b6d691d68366@haskell.org> #10184: Coercible solver incomplete with recursive newtypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:26:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:26:27 -0000 Subject: [GHC] #10185: Coercible solver incomplete with non-variable transitivity In-Reply-To: <047.c39f23321361d46a92df4fbbf1d28dbd@haskell.org> References: <047.c39f23321361d46a92df4fbbf1d28dbd@haskell.org> Message-ID: <062.4f589ba25af0f6c2645f6a4e3e91f02b@haskell.org> #10185: Coercible solver incomplete with non-variable transitivity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:26:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:26:27 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.93a880b7db9bbf35952b3019a140935e@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8550, #10079 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:26:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:26:27 -0000 Subject: [GHC] #9554: Pathological type family turns type error into runtime loop In-Reply-To: <047.10c0d6cec996432d07767233097ef363@haskell.org> References: <047.10c0d6cec996432d07767233097ef363@haskell.org> Message-ID: <062.d8927e856d2354c14deea55af17b34a7@haskell.org> #9554: Pathological type family turns type error into runtime loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:26:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:26:27 -0000 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found In-Reply-To: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> References: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> Message-ID: <062.cfbef958f2f50a6b8cd73a50485d94ed@haskell.org> #10158: Panic compiling singletons: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:26:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:26:27 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.c3ac35d6fd2c765518a1f0e229ec1d30@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:26:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:26:27 -0000 Subject: [GHC] #10139: Coercible causes ghc to hang In-Reply-To: <053.ded1fc4757c965f068c092100f8f55ce@haskell.org> References: <053.ded1fc4757c965f068c092100f8f55ce@haskell.org> Message-ID: <068.ce41e6f0ef2c27e98bf2d7b778511f96@haskell.org> #10139: Coercible causes ghc to hang -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:31:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:31:37 -0000 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found In-Reply-To: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> References: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> Message-ID: <062.123c9eca9d840d14bb0e41ff2860a346@haskell.org> #10158: Panic compiling singletons: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: This should take care of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:32:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:32:38 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.1ae66e53d4f41d6fa83ed694a7674a58@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: indexed- at runtime | types/should_fail/T7788 Blocked By: | Blocking: Related Tickets: #8550, #10079 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => indexed-types/should_fail/T7788 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:33:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:33:24 -0000 Subject: [GHC] #9554: Pathological type family turns type error into runtime loop In-Reply-To: <047.10c0d6cec996432d07767233097ef363@haskell.org> References: <047.10c0d6cec996432d07767233097ef363@haskell.org> Message-ID: <062.9d1d8613381ec2820577de58d1be32e9@haskell.org> #9554: Pathological type family turns type error into runtime loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: indexed- Related Tickets: | types/should_fail/T9554 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => indexed-types/should_fail/T9554 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:34:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:34:25 -0000 Subject: [GHC] #8708: Kind annotation in tuple not parsed In-Reply-To: <047.7299eca00fb25a2e788e2c82e2894717@haskell.org> References: <047.7299eca00fb25a2e788e2c82e2894717@haskell.org> Message-ID: <062.57e6cdd9432d385d0fb5636b9bfbe764@haskell.org> #8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): What about the following: * unboxed tuples: `(# Int, Int :: * #)` * lists: `[ Int :: * ]` * parallel arrays: `[: Int :: * :]` * default declarations: `default ( Int :: * )` Currently all of those don't allow types with kind annotation but without parenthesis. They only allow `ctype`s: {{{ -- A ctype is a for-all type ctype :: { RdrNameHsType } : 'forall' tv_bndrs '.' ctype { mkHsForAllTy (Just $2) [] $4 } | context '=>' type { mkHsForAllTy Nothing $1 $3 } -- A type of form (context => type) is an *implicit* HsForAllTy | type { $1 } }}} Implementation wise it would be nice to keep doing the same for all: either allow kind annotation without parenthesis, or keep the status quo (since 2002). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:36:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:36:00 -0000 Subject: [GHC] #10184: Coercible solver incomplete with recursive newtypes In-Reply-To: <047.7509967c1582acd23d4cd58fb93af3d5@haskell.org> References: <047.7509967c1582acd23d4cd58fb93af3d5@haskell.org> Message-ID: <062.8e28f3b8be735ff83d5cb59adae2687d@haskell.org> #10184: Coercible solver incomplete with recursive newtypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10184 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T10184 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:36:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:36:28 -0000 Subject: [GHC] #8550: GHC builds recursive coerctions when using recursive type families In-Reply-To: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> References: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> Message-ID: <061.112a6bab79cd2771f095d6397733f81f@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- Blocked By: | types/should_fail/T8550 Related Tickets: #7788 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => indexed-types/should_fail/T8550 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:36:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:36:34 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b In-Reply-To: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> References: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> Message-ID: <059.48aa8c978765706dace38c519f05158c@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: #7788, #8550 | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:36:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:36:48 -0000 Subject: [GHC] #10185: Coercible solver incomplete with non-variable transitivity In-Reply-To: <047.c39f23321361d46a92df4fbbf1d28dbd@haskell.org> References: <047.c39f23321361d46a92df4fbbf1d28dbd@haskell.org> Message-ID: <062.a8ecaa414c37e867cefba1e353fe83c5@haskell.org> #10185: Coercible solver incomplete with non-variable transitivity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10185 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T10185 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 16:37:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 16:37:22 -0000 Subject: [GHC] #10139: Coercible causes ghc to hang In-Reply-To: <053.ded1fc4757c965f068c092100f8f55ce@haskell.org> References: <053.ded1fc4757c965f068c092100f8f55ce@haskell.org> Message-ID: <068.e8285140a0caa1fcb6c9b3ed0ecc9960@haskell.org> #10139: Coercible causes ghc to hang -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: indexed- Related Tickets: | types/should_compile/T10139 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => indexed-types/should_compile/T10139 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 19:14:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 19:14:06 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.3f95deda21d548c3c5a3c823880225a7@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Sounds good, thanks! Will push this as soon as the build validates on phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 19:33:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 19:33:55 -0000 Subject: [GHC] #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! In-Reply-To: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> References: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> Message-ID: <061.d009541c8ed20d72b6924cd76aaec2b0@haskell.org> #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! ---------------------------------+----------------------------------------- Reporter: jamshid | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by refold): Replying to [comment:2 goldfire]: > Cabal folks: is there a way to get `cabal build` to spit out exactly what it's doing? `cabal build -v3`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 19:34:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 19:34:22 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.2374b615534a373daf4e59dfc9355175@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"5673bfc49ec1e54a1540197078041a9da9754fa3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5673bfc49ec1e54a1540197078041a9da9754fa3" exprIsBottom should look through type lambdas as evaluting (\ (@ a) -> e) diverges if and only if evaluating e diverges. This was found in the context of #10180. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 19:34:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 19:34:23 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.d5b2b0dc5a8f24883810eb089a7feb31@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"a0678f1f0e62496c108491e1c80d5eef3936474a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a0678f1f0e62496c108491e1c80d5eef3936474a" New Lint check: no alternatives implies bottoming expression detected either by exprIsBottom or by an empty type. This was suggested by SPJ and fixes #10180. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 19:43:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 19:43:12 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.a57b0b95cef78f883c0e9e0d9bebacde@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 19:46:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 19:46:47 -0000 Subject: [GHC] #10181: Lint check: arity invariant In-Reply-To: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> References: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> Message-ID: <061.b641a8af55325032defa818244bcbb6f@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:751 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"567db32b074860723e2b7c38f119b1880a803775/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="567db32b074860723e2b7c38f119b1880a803775" New lint check: Check idArity invariants (#10181) The arity of an id should not be larger than what the type allows, and it should also not contradict the strictness signature. This adds a lint check for that. This broke test T8743, uncovering a bug in the SOURCE import machinery, which is now filed as #10182. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 19:46:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 19:46:47 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.c9e386ada3c90c817add4ae79ff90419@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"567db32b074860723e2b7c38f119b1880a803775/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="567db32b074860723e2b7c38f119b1880a803775" New lint check: Check idArity invariants (#10181) The arity of an id should not be larger than what the type allows, and it should also not contradict the strictness signature. This adds a lint check for that. This broke test T8743, uncovering a bug in the SOURCE import machinery, which is now filed as #10182. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 19:47:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 19:47:53 -0000 Subject: [GHC] #10181: Lint check: arity invariant In-Reply-To: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> References: <046.f8da9bf8eb8c5c91d5a26d3f26e33176@haskell.org> Message-ID: <061.4eea6fc4ab40e109dcff40689094a0c6@haskell.org> #10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:751 -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 20:06:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 20:06:04 -0000 Subject: [GHC] #10183: Warning for redundant constraints: interaction with pattern matching In-Reply-To: <046.02647e82b4059f07aa24c7e2e29b1e1f@haskell.org> References: <046.02647e82b4059f07aa24c7e2e29b1e1f@haskell.org> Message-ID: <061.c2e090ad0c2e714f634dd1f31387bb41@haskell.org> #10183: Warning for redundant constraints: interaction with pattern matching -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * version: 7.8.4 => 7.11 Comment: Afaik this only occurs on GHC HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 20:50:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 20:50:03 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.c7a02be82365e893ab0180191e9c7c90@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Wuuld it be possible to add a `Note` to `isEmptyTy` and the call in CoreLint, explaiing what is going on, and referring to this ticket. As its stands there is zero commentary. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 21:16:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 21:16:26 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.180a50ac6521887db897d70db4c81b66@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"8f08069668f12ce019be3277bc4baacb477a77ed/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f08069668f12ce019be3277bc4baacb477a77ed" Add Note [No alternatives lint check] in a follow up to #10180. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 21:17:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 21:17:30 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.cfc42a674fb675ebfdf11d51dac9d46b@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Of course, sorry for the negligence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 21:22:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 21:22:50 -0000 Subject: [GHC] #10186: exprIsBottom should include isEmptyTy Message-ID: <046.218cfdf18b449d8b2bcf391c5e825378@haskell.org> #10186: exprIsBottom should include isEmptyTy -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is a spin-of of comment:3:ticket:10180: `exprIsBottom` (which currently only takes strictnes signatures into account) should also look at the type, via the new `isEmptyTy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 21:27:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 21:27:29 -0000 Subject: [GHC] #10186: exprIsBottom should include isEmptyTy In-Reply-To: <046.218cfdf18b449d8b2bcf391c5e825378@haskell.org> References: <046.218cfdf18b449d8b2bcf391c5e825378@haskell.org> Message-ID: <061.dea2746af4e85df2dea2c2657a9a5c26@haskell.org> #10186: exprIsBottom should include isEmptyTy -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I created a DR for this very small change, basically as a quick way to get a validate run started before I go to bed :-) Phab:D754 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 21:57:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 21:57:07 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.9a2813e71689e668cd60568ffd326535@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D745 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"42448e3757f25735a0a5b5e2b7ee456b5e8b0039/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="42448e3757f25735a0a5b5e2b7ee456b5e8b0039" Do version specific detection of LLVM tools (#10170). The LLVM developers seem to make breaking changes in the LLVM IR language between major releases. As a consumer of the LLVM tools GHC now needs to be locked more tightly to a single version of the LLVM tools. GHC HEAD currently only supports LLVM version 3.6. This commit changes the configure script to look for `llc-3.6` and `opt-3.6` before looking for `llc` and `opt`. If the former are not found, but the later are, check that they actually are version 3.6. At the same time, when detecting known problems with the LLVM tools (ie #9439) test for it using the versions of the LLVM tools retrieved from the bootstrap compiler's settings file. Test Plan: Manual testing. Reviewers: thomie, rwbarton, nomeata, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D745 GHC Trac Issues: #10170 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 21:57:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 21:57:08 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.1e56a874312169707fde749242271407@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.4 Component: Compiler (LLVM) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: 9268 | Differential Revisions: Phab:D150 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"42448e3757f25735a0a5b5e2b7ee456b5e8b0039/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="42448e3757f25735a0a5b5e2b7ee456b5e8b0039" Do version specific detection of LLVM tools (#10170). The LLVM developers seem to make breaking changes in the LLVM IR language between major releases. As a consumer of the LLVM tools GHC now needs to be locked more tightly to a single version of the LLVM tools. GHC HEAD currently only supports LLVM version 3.6. This commit changes the configure script to look for `llc-3.6` and `opt-3.6` before looking for `llc` and `opt`. If the former are not found, but the later are, check that they actually are version 3.6. At the same time, when detecting known problems with the LLVM tools (ie #9439) test for it using the versions of the LLVM tools retrieved from the bootstrap compiler's settings file. Test Plan: Manual testing. Reviewers: thomie, rwbarton, nomeata, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D745 GHC Trac Issues: #10170 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 22:34:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 22:34:52 -0000 Subject: [GHC] #5001: makeCorePair: arity missing In-Reply-To: <045.01643f91fbc10ebef1f612bc5674a3a7@haskell.org> References: <045.01643f91fbc10ebef1f612bc5674a3a7@haskell.org> Message-ID: <060.c2f0d040e8a472c35a6aa245ef6b2d1e@haskell.org> #5001: makeCorePair: arity missing -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | deSugar/should_compile/T5001 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ryan.gl.scott@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 23 22:58:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Mar 2015 22:58:15 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.ef6577ba6ed7e6906aa80849915ec5cb@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D745 -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: Since this patch is all about llvm-3.6, this is a 7.11+ specific patch and hence does not need to be backported to 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 01:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 01:08:30 -0000 Subject: [GHC] #10187: Panic: RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order; bad blockId c8xHd Message-ID: <045.854a7c2e83fb00658c4034e982e2f0f4@haskell.org> #10187: Panic: RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order; bad blockId c8xHd -----------------------------------+--------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: #9541, #9031 Differential Revisions: | -----------------------------------+--------------------------------------- I?ve found another instance of the elusive `RegAlloc.Liveness.computeLivenss` bug, by attempting to bootstrap ''cabal-install'' 1.20.0.6 with GHC 7.8.4 on 32-bit CentOS 6, released on 27/05/2013 (available on [https://aws.amazon.com/marketplace/pp/B00A6KZBC6/ Amazon EC2]). Unfortunately, I?m unable to reproduce the bug on a subsequent attempt. Cosmic rays? {{{ Configuring text-1.1.0.1... Building text-1.1.0.1... Preprocessing library text-1.1.0.1... [ 1 of 43] Compiling Data.Text.Internal.Read ( Data/Text/Internal/Read.hs, dist/build/Data/Text/Internal/Read.o ) [ 2 of 43] Compiling Data.Text.Internal.Encoding.Utf32 ( Data/Text/Internal/Encoding/Utf32.hs, dist/build/Data/Text/Internal/Encoding/Utf32.o ) [ 3 of 43] Compiling Data.Text.Internal.Fusion.Size ( Data/Text/Internal/Fusion/Size.hs, dist/build/Data/Text/Internal/Fusion/Size.o ) [ 4 of 43] Compiling Data.Text.Internal.Builder.RealFloat.Functions ( Data/Text/Internal/Builder/RealFloat/Functions.hs, dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o ) [ 5 of 43] Compiling Data.Text.Internal.Builder.Int.Digits ( Data/Text/Internal/Builder/Int/Digits.hs, dist/build/Data/Text/Internal/Builder/Int/Digits.o ) [ 6 of 43] Compiling Data.Text.Internal.Fusion.Types ( Data/Text/Internal/Fusion/Types.hs, dist/build/Data/Text/Internal/Fusion/Types.o ) [ 7 of 43] Compiling Data.Text.Internal.Fusion.CaseMapping ( Data/Text/Internal/Fusion/CaseMapping.hs, dist/build/Data/Text/Internal/Fusion/CaseMapping.o ) [ 8 of 43] Compiling Data.Text.Encoding.Error ( Data/Text/Encoding/Error.hs, dist/build/Data/Text/Encoding/Error.o ) [ 9 of 43] Compiling Data.Text.Internal.Unsafe.Shift ( Data/Text/Internal/Unsafe/Shift.hs, dist/build/Data/Text/Internal/Unsafe/Shift.o ) [10 of 43] Compiling Data.Text.Internal.Encoding.Utf16 ( Data/Text/Internal/Encoding/Utf16.hs, dist/build/Data/Text/Internal/Encoding/Utf16.o ) [11 of 43] Compiling Data.Text.Internal.Functions ( Data/Text/Internal/Functions.hs, dist/build/Data/Text/Internal/Functions.o ) [12 of 43] Compiling Data.Text.Internal.Unsafe ( Data/Text/Internal/Unsafe.hs, dist/build/Data/Text/Internal/Unsafe.o ) [13 of 43] Compiling Data.Text.Internal.Fusion.Common ( Data/Text/Internal/Fusion/Common.hs, dist/build/Data/Text/Internal/Fusion/Common.o ) [14 of 43] Compiling Data.Text.Array ( Data/Text/Array.hs, dist/build/Data/Text/Array.o ) [15 of 43] Compiling Data.Text.Internal.Unsafe.Char ( Data/Text/Internal/Unsafe/Char.hs, dist/build/Data/Text/Internal/Unsafe/Char.o ) [16 of 43] Compiling Data.Text.Internal ( Data/Text/Internal.hs, dist/build/Data/Text/Internal.o ) [17 of 43] Compiling Data.Text.Unsafe ( Data/Text/Unsafe.hs, dist/build/Data/Text/Unsafe.o ) [18 of 43] Compiling Data.Text.Internal.Private ( Data/Text/Internal/Private.hs, dist/build/Data/Text/Internal/Private.o ) [19 of 43] Compiling Data.Text.Internal.Fusion ( Data/Text/Internal/Fusion.hs, dist/build/Data/Text/Internal/Fusion.o ) [20 of 43] Compiling Data.Text.Internal.Encoding.Fusion.Common ( Data/Text/Internal/Encoding/Fusion/Common.hs, dist/build/Data/Text/Internal/Encoding/Fusion/Common.o ) [21 of 43] Compiling Data.Text.Internal.Encoding.Utf8 ( Data/Text/Internal/Encoding/Utf8.hs, dist/build/Data/Text/Internal/Encoding/Utf8.o ) [22 of 43] Compiling Data.Text.Internal.Encoding.Fusion ( Data/Text/Internal/Encoding/Fusion.hs, dist/build/Data/Text/Internal/Encoding/Fusion.o ) [23 of 43] Compiling Data.Text.Internal.Lazy.Encoding.Fusion ( Data/Text/Internal/Lazy/Encoding/Fusion.hs, dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o ) [24 of 43] Compiling Data.Text.Internal.Search ( Data/Text/Internal/Search.hs, dist/build/Data/Text/Internal/Search.o ) [25 of 43] Compiling Data.Text ( Data/Text.hs, dist/build/Data/Text.o ) [26 of 43] Compiling Data.Text.Encoding ( Data/Text/Encoding.hs, dist/build/Data/Text/Encoding.o ) [27 of 43] Compiling Data.Text.Foreign ( Data/Text/Foreign.hs, dist/build/Data/Text/Foreign.o ) [28 of 43] Compiling Data.Text.Internal.IO ( Data/Text/Internal/IO.hs, dist/build/Data/Text/Internal/IO.o ) [29 of 43] Compiling Data.Text.IO ( Data/Text/IO.hs, dist/build/Data/Text/IO.o ) [30 of 43] Compiling Data.Text.Internal.Lazy ( Data/Text/Internal/Lazy.hs, dist/build/Data/Text/Internal/Lazy.o ) [31 of 43] Compiling Data.Text.Internal.Lazy.Fusion ( Data/Text/Internal/Lazy/Fusion.hs, dist/build/Data/Text/Internal/Lazy/Fusion.o ) [32 of 43] Compiling Data.Text.Internal.Lazy.Search ( Data/Text/Internal/Lazy/Search.hs, dist/build/Data/Text/Internal/Lazy/Search.o ) [33 of 43] Compiling Data.Text.Lazy.Internal ( Data/Text/Lazy/Internal.hs, dist/build/Data/Text/Lazy/Internal.o ) [34 of 43] Compiling Data.Text.Lazy ( Data/Text/Lazy.hs, dist/build/Data/Text/Lazy.o ) [35 of 43] Compiling Data.Text.Internal.Builder ( Data/Text/Internal/Builder.hs, dist/build/Data/Text/Internal/Builder.o ) [36 of 43] Compiling Data.Text.Lazy.Builder ( Data/Text/Lazy/Builder.hs, dist/build/Data/Text/Lazy/Builder.o ) [37 of 43] Compiling Data.Text.Internal.Builder.Functions ( Data/Text/Internal/Builder/Functions.hs, dist/build/Data/Text/Internal/Builder/Functions.o ) [38 of 43] Compiling Data.Text.Lazy.Builder.Int ( Data/Text/Lazy/Builder/Int.hs, dist/build/Data/Text/Lazy/Builder/Int.o ) [39 of 43] Compiling Data.Text.Lazy.IO ( Data/Text/Lazy/IO.hs, dist/build/Data/Text/Lazy/IO.o ) [40 of 43] Compiling Data.Text.Lazy.Read ( Data/Text/Lazy/Read.hs, dist/build/Data/Text/Lazy/Read.o ) [41 of 43] Compiling Data.Text.Lazy.Builder.RealFloat ( Data/Text/Lazy/Builder/RealFloat.hs, dist/build/Data/Text/Lazy/Builder/RealFloat.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for i386-unknown-linux): RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId c8xHd [NONREC c8xHG: jmp *-4(%ebx), NONREC c8xHF: movl $12,828(%ebx) jmp *stg_gc_unpt_r1 at got(%vI_n8Wmo), NONREC c8xHE: movl %vI_n8Wmo,%vI_n8WmH addl $sat_s8qTs{v}_info at gotoff,%vI_n8WmH movl %vI_n8WmH,-8(%edi) movl 4(%ebp),%vI_n8WmI movl %vI_n8WmI,-4(%edi) movl 16(%ebp),%vI_n8WmJ movl %vI_n8WmJ,(%edi) leal -7(%edi),%esi addl $20,%ebp jmp *(%ebp), NONREC c8xHz: movl $48,828(%ebx) movl %vI_n8Wmo,%vI_n8WmF addl $block{v c8xEh}_info at gotoff,%vI_n8WmF movl %vI_n8WmF,(%ebp) movl %vI_s8qTz,%esi movl %vI_s8qTx,4(%ebp) jmp *stg_gc_unbx_r1 at got(%vI_n8Wmo), NONREC c8xHq: movl %vI_c8xEw,%esi incl 8(%ebp) addl $8,%ebp jmp *stg_ap_n_fast at got(%vI_n8Wmo), NONREC c8xHp: movl %vI_c8xEw,%esi addl $8,%ebp jmp *stg_ap_n_fast at got(%vI_n8Wmo), NONREC c8xHi: jmp *(%esi), NONREC c8xGZ: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl 4(%ebp),%vI_c8xEw movl %esi,%vI_n8Wmw andl $3,%vI_n8Wmw cmpl $2,%vI_n8Wmw jae _c8xHp jmp _c8xHq, NONREC c8xHy: movl %vI_n8Wmo,%vI_n8Wmy addl $lvl65{v s8qTB}_info at gotoff,%vI_n8Wmy movl %vI_n8Wmy,-44(%edi) movl %vI_s8qTz,-36(%edi) movl %vI_n8Wmo,%vI_n8WmA addl $a28{v s8qTD}_info at gotoff,%vI_n8WmA movl %vI_n8WmA,-32(%edi) movl %vI_s8qTd,-28(%edi) movl %vI_s8qTh,-24(%edi) movl %vI_s8qTk,-20(%edi) movl %vI_s8qTx,-16(%edi) leal -44(%edi),%vI_c8xEn movl %vI_c8xEn,-12(%edi) movl %vI_s8qRK,-8(%edi) movl %vI_s8qTj,-4(%edi) movl %vI_s8qTz,(%edi) movl %vI_n8Wmo,%vI_n8WmC addl $block{v c8xGZ}_info at gotoff,%vI_n8WmC movl %vI_n8WmC,16(%ebp) movl %vI_c8xEn,%esi leal -30(%edi),%vI_n8WmD movl %vI_n8WmD,20(%ebp) addl $16,%ebp testl $3,%esi jne _c8xGZ jmp _c8xHi, NONREC c8xGX: addl $12,%edi cmpl 804(%ebx),%edi ja _c8xHF jmp _c8xHE, NONREC c8xEi: addl $48,%edi cmpl 804(%ebx),%edi ja _c8xHz jmp _c8xHy, NONREC c8xHe: movl %esi,%vI_s8qTx movl $65533,%vI_s8qTz jmp _c8xEi, NONREC c8xEh: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl 20(%ebp),%vI_s8qRK movl 12(%ebp),%vI_s8qTd movl 16(%ebp),%vI_s8qTh movl 24(%ebp),%vI_s8qTj movl 8(%ebp),%vI_s8qTk movl 4(%ebp),%vI_s8qTx movl %esi,%vI_s8qTz jmp _c8xEi, NONREC c8xEb: jmp *(%esi), NONREC c8xEa: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl 20(%ebp),%vI_s8qRK movl 12(%ebp),%vI_s8qTd movl 16(%ebp),%vI_s8qTh movl 24(%ebp),%vI_s8qTj movl 8(%ebp),%vI_s8qTk movl 4(%ebp),%vI_s8qTw movl %vI_s8qTw,%vI_n8Wms andl $2095104,%vI_n8Wms cmpl $55296,%vI_n8Wms jne _c8xHd jmp _c8xHe, NONREC c8xE6: jmp *(%esi), NONREC c8xE5: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl %vI_n8Wmo,%vI_n8Wmq addl $block{v c8xEa}_info at gotoff,%vI_n8Wmq movl %vI_n8Wmq,(%ebp) movl 3(%esi),%vI_s8qTw movl 4(%ebp),%esi movl %vI_s8qTw,4(%ebp) testl $3,%esi jne _c8xEa jmp _c8xEb, NONREC c8xGW: movl %vI_n8Wmo,%vI_n8Wmu addl $block{v c8xE5}_info at gotoff,%vI_n8Wmu movl %vI_n8Wmu,-8(%ebp) movl %esi,%vI_s8qTk movl 6(%esi),%vI_s8qTu movl 2(%esi),%esi movl %vI_s8qTu,-4(%ebp) movl %vI_s8qTk,(%ebp) addl $-8,%ebp testl $3,%esi jne _c8xE5 jmp _c8xE6, NONREC c8xDC: jmp *(%esi), NONREC c8xDB: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl %esi,%vI_n8Wmn andl $3,%vI_n8Wmn cmpl $2,%vI_n8Wmn jae _c8xGW jmp _c8xGX, NONREC c8xHH: movl %vI_n8Wmo,%vI_n8WmL addl $block{v c8xDB}_info at gotoff,%vI_n8WmL movl %vI_n8WmL,-12(%ebp) movl %esi,%vI_s8qTh movl 2(%esi),%vI_s8qTd movl 6(%esi),%vI_s8qRK movl (%ebp),%esi movl %vI_s8qTd,-8(%ebp) movl %vI_s8qTh,-4(%ebp) movl %vI_s8qRK,(%ebp) addl $-12,%ebp testl $3,%esi jne _c8xDB jmp _c8xDC, NONREC c8xGY: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo leal -20(%ebp),%vI_n8Wml cmpl 796(%ebx),%vI_n8Wml jb _c8xHG jmp _c8xHH] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 01:18:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 01:18:13 -0000 Subject: [GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel In-Reply-To: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> References: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> Message-ID: <059.bec3f517e652e2df035103c227bf0a1d@haskell.org> #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Changes (by erikd): * owner: => erikd Comment: Currently `ghc-stage2` segfaults when compiling the file `libraries/parallel/Control/Parallel/Strategies.hs`. However, following programs not only compile but also run correctly when compiled with the `-threaded` flag: * Simple "hello world" program. * Simple program that uses `forkIO` to create a couple of threads and `threadDelay` to exercise the threading before printing something and exiting. This means I cannot find any small clean test case and will have to debug GHC itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 01:20:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 01:20:33 -0000 Subject: [GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel In-Reply-To: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> References: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> Message-ID: <059.3444603fdfea1c1263e4d704b1dbe1d7@haskell.org> #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by rwbarton): It could be a problem with GC then, I remember some crashes with dll-split that were not reproduceable with "hello world" and the reason was that GC never ran in the latter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 05:00:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 05:00:09 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed Message-ID: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Whereas other type operators (whether used as type families or used as data constructors) can be safely used in a prefix form, only the type- level cons of the built-in list kind can't be used in a prefix form. It really is a problem because we don't have any means to express type- level cons itself in source code. This for example prevents us from writing a generic type-level foldr that takes the built-in list and other similar data types alike. In a ghci: {{{#!hs > :set -XDataKinds -XTypeOperators > data Listy a = a ::: Listy a > :kind! (:::) (:::) :: k -> Listy k -> Listy k = forall (k :: BOX). (':::) > :kind! (:) :1:2: parse error on input ?:? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 08:26:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 08:26:15 -0000 Subject: [GHC] #10186: exprIsBottom should include isEmptyTy In-Reply-To: <046.218cfdf18b449d8b2bcf391c5e825378@haskell.org> References: <046.218cfdf18b449d8b2bcf391c5e825378@haskell.org> Message-ID: <061.0fbc8b5c7e888c0148d0a006941f43fd@haskell.org> #10186: exprIsBottom should include isEmptyTy -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"7062ebe0ce92c191d87e993bd2497275976b9452/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7062ebe0ce92c191d87e993bd2497275976b9452" exprIsBottom: Make use of isEmptyTy (#10186) Any expression with of empty type is necessary bottom, so we can use that here. No effects known, but it is the right thing to do and validate, so lets do it. Differential Revision: https://phabricator.haskell.org/D754 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 08:26:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 08:26:42 -0000 Subject: [GHC] #10186: exprIsBottom should include isEmptyTy In-Reply-To: <046.218cfdf18b449d8b2bcf391c5e825378@haskell.org> References: <046.218cfdf18b449d8b2bcf391c5e825378@haskell.org> Message-ID: <061.ddecb3bcfc42247a35a5b1355d12d3bf@haskell.org> #10186: exprIsBottom should include isEmptyTy -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Makes sense and validates; pushed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 08:37:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 08:37:02 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.294806a2ae5c9baf55b33070f01ef0ce@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Good point. This is just a question of fixing the parser. Would anyone like to have a go? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 09:46:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 09:46:13 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.28e2bb9431385eebe02612ca6bbd7426@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Parser) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 10:31:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 10:31:10 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.d93b7b9cd838a5dfae9d66deb87f7ebd@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"6cf0c7962c582eefb84cdf2735504d034fb16314/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6cf0c7962c582eefb84cdf2735504d034fb16314" Some stress tests for the empty case linter This is a variation of T2431 where the emptyness of the type is hidden behind a newtype, a type family and a closed type family. In all cases, it would be sound for the compiler to determine that the equality type is empty and the case alternatives may be dropped. At the moment, GHC does _not_ determine that. But if it ever does, this test ensures that we do not forget to make the lint from #10180 smarter as well. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 10:43:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 10:43:27 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.595c65da3f510ae8b2ede2b8787a95f5@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Description changed by Kinokkory: Old description: > Whereas other type operators (whether used as type families or used as > data constructors) can be safely used in a prefix form, only the type- > level cons of the built-in list kind can't be used in a prefix form. > > It really is a problem because we don't have any means to express type- > level cons itself in source code. This for example prevents us from > writing a generic type-level foldr that takes the built-in list and other > similar data types alike. > > In a ghci: > > {{{#!hs > > :set -XDataKinds -XTypeOperators > > data Listy a = a ::: Listy a > > :kind! (:::) > (:::) :: k -> Listy k -> Listy k > = forall (k :: BOX). (':::) > > :kind! (:) > > :1:2: parse error on input ?:? > }}} New description: Whereas other type operators (whether used as type families or used as data constructors) can be safely used in a prefix form, only the type- level cons of the built-in list kind can't be used in a prefix form. It really is a problem because we don't have any means to express the type-level cons itself in source code. This for example prevents us from writing a generic type-level foldr that takes the built-in list and other similar data types alike. In a ghci: {{{#!hs > :set -XDataKinds -XTypeOperators > data Listy a = a ::: Listy a | Nily > :kind! (:::) (:::) :: k -> Listy k -> Listy k = forall (k :: BOX). (':::) > :kind! (:) :1:2: parse error on input ?:? }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 11:34:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 11:34:34 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.8dec0530cbd968e71586ba106d5bdab9@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D646 -------------------------------------+------------------------------------- Comment (by darchon): I'm terribly sorry for, once again, bringing up tickets late in the release cycle... but can the above fix be included in ghc 7.10? I'm getting: {{{ ~/devel/test$ ghci Blah.hs GHCi, version 7.10.0.20150323: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Blah ( Blah.hs, interpreted ) Blah.hs:7:17: Found hole ?_? with type: t2 -> a1 -> t3 Where: ?t2? is a rigid type variable bound by the inferred type of copy :: Num a1 => t2 -> a1 -> t3 at Blah.hs:8:9 ?t3? is a rigid type variable bound by the inferred type of copy :: Num a1 => t2 -> a1 -> t3 at Blah.hs:8:9 ?a1? is a rigid type variable bound by the inferred type of copy :: Num a1 => t2 -> a1 -> t3 at Blah.hs:8:9 To use the inferred type, enable PartialTypeSignatures Relevant bindings include ws1 :: () (bound at Blah.hs:6:11) foo :: Meta -> t3 (bound at Blah.hs:6:1) In the type signature for ?copy?: _ In the expression: let copy :: _ copy w from = copy w 1 in copy ws1 1 In an equation for ?foo?: foo (Meta ws1) = let copy :: _ copy w from = copy w 1 in copy ws1 1 Blah.hs:8:9: No instance for (Num a) When checking that ?copy? has the specified type copy :: forall t t1 a. t -> a -> t1 Probable cause: the inferred type is ambiguous In the expression: let copy :: _ copy w from = copy w 1 in copy ws1 1 In an equation for ?foo?: foo (Meta ws1) = let copy :: _ copy w from = copy w 1 in copy ws1 1 Blah.hs:9:13: Couldn't match expected type ?t? with actual type ?()? ?t? is untouchable inside the constraints () bound by the inferred type of foo :: Meta -> t1 at Blah.hs:(6,1)-(9,17)ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150323 for x86_64-apple-darwin): No skolem info: t_avM[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Also, this is ''not'' mission critical for me! So if it's postponed to a later release then it's no problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 12:02:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 12:02:54 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.0aa05414f191ee4ba6a515e681e1bccc@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): It's unfortunate (and a bug) that the code you wrote doesn't work, but there is support for the feature you want: {{{ > :kind '(:) '(:) :: k -> [k] -> [k] }}} Note the `'`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 12:29:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 12:29:10 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.ded812fea0b3ce0abab904b77dd0e9c5@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Kinokkory): Oh, I didn't know that. Thanks a lot! In a ghci: {{{#!hs > :kind! '(:::) '(:::) :: k -> Listy k -> Listy k = forall (k :: BOX). (':::) > :kind! (':::) :1:3: parse error on input ?:::? > :kind! (':) :1:3: parse error on input ?:? }}} The message "forall (k :: BOX). (':::)" seems inconsistent with the parsing mechanism that allows "'(:::)" instead of (':::). I'll report this as another new bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 13:52:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 13:52:21 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.eeca6e0dcc2c3ce1b274ba88d9deea4b@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"33cfa5ff9db4e7886b3e7c2eed5ac1c75436bc4c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="33cfa5ff9db4e7886b3e7c2eed5ac1c75436bc4c" More comments (related to Trac #10180) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 13:54:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 13:54:24 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally Message-ID: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the constructor. On the other hand, messages of GHC and GHCi indicate that a data constructor operator in a prefix form is promoted by putting `'` before the constructor! (as in `forall (k :: BOX) (k :: BOX). (':*)` below.) I believe that this is a matter of parsing. The parser should admit `(':*)` as well as `'(:*)` for the naturalness of the syntax. In a GHCi: {{{#!hs > :set -XDataKinds -XTypeOperators > data a :* b = a :* b > :kind! Int :* Int Int :* Int :: * = Int :* Int > :kind! Int ':* Int Int ':* Int :: * :* * = Int ':* Int > :kind! (:*) (:*) :: * -> * -> * = (:*) > :kind! '(:*) '(:*) :: k -> k1 -> k :* k1 = forall (k :: BOX) (k :: BOX). (':*) > :kind! (':*) :1:3: parse error on input ?:*? }}} (By the way I assume that Template Haskell quotes (`'function` and `''Type`) are parsed by the same mechanism as the one for the explicit promotion syntax. I hope both styles of quotes for prefix operators will be admitted because currently only the `'(` `''(` style is admitted.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 14:30:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 14:30:03 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.02bc59cddce2adfed8a420599c3c0d06@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D646 -------------------------------------+------------------------------------- Changes (by hvr): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 14:39:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 14:39:24 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.105ce782a52cd5ca329507bee825952d@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: thomasw Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D646 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 15:28:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 15:28:30 -0000 Subject: [GHC] #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes In-Reply-To: <042.2351aa32b11f999d614978d597e46a77@haskell.org> References: <042.2351aa32b11f999d614978d597e46a77@haskell.org> Message-ID: <057.ed83a156309b6528921c9510fb4d062e@haskell.org> #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D736 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 15:28:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 15:28:45 -0000 Subject: [GHC] #10164: Cleanup test framework string formatting In-Reply-To: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> References: <045.bd3db3ff7d0f3406afa074275e2d70de@haskell.org> Message-ID: <060.472be8d7b834a8b5796919baf2481567@haskell.org> #10164: Cleanup test framework string formatting -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 15:32:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 15:32:41 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.94795f9a587a871dcb0297854bfd15ab@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Driver | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D715 Related Tickets: #9268 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * milestone: 7.12.1 => 7.10.1 Comment: These were merged into `ghc-7.10`, thanks Erik! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 15:33:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 15:33:45 -0000 Subject: [GHC] Batch modify: #10045, #8276, #9929, #10110, #10052 Message-ID: <20150324153345.ECA4B3A2FF@ghc.haskell.org> Batch modification to #10045, #8276, #9929, #10110, #10052 by thoughtpolice: milestone to 7.10.2 Comment: Moving to GHC 7.10.2. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 15:34:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 15:34:42 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.fd74dd72557f757b348937e64d589917@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: thomasw Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D646 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Sorry, the patch in question is a bit tricky to merge as it has some dependencies. We may be able to revisit this one for 7.10.2, so I've pushed it off to said milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 15:45:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 15:45:24 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.3e6cd5a303050f882f0c795d18978714@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D646 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: thomasw => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 17:18:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 17:18:31 -0000 Subject: [GHC] #9225: Missing syntax error for package qualified import with version number In-Reply-To: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> References: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> Message-ID: <060.8c22f95571a43a7dc138991c1f9ceb40@haskell.org> #9225: Missing syntax error for package qualified import with version number -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | Blocking: Blocked By: | Differential Revisions: Phab:D755 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D755 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 18:12:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 18:12:45 -0000 Subject: [GHC] #8029: batch-mode recompilation checking sometimes fails In-Reply-To: <045.fbb1c0736cf81083c94a9ff0372ae621@haskell.org> References: <045.fbb1c0736cf81083c94a9ff0372ae621@haskell.org> Message-ID: <060.13bb1e29dfe9119d2bddf7f61797e85a@haskell.org> #8029: batch-mode recompilation checking sometimes fails -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | recompilation, batch-mode Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: The package name is now mentioned in the error message. In commit 7897623599db0a2b0e9b8870fdb8b2401396b3a9: {{{ Author: Simon Peyton Jones Date: Tue Aug 2 17:29:16 2011 +0100 Improve pretty-printing for ambiguous imports etc }}} In commit 87a5ef5f2cc20acde5febae1e3ce6989caf8accc: {{{ Author: Simon Peyton Jones <> Date: Tue Aug 2 18:00:28 2011 +0100 Error message changes due to pretty-printing of provenances }}} Since there is a consensus to not add any extra checks to one-shot compilation mode, I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 18:18:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 18:18:39 -0000 Subject: [GHC] #8029: batch-mode recompilation checking sometimes fails In-Reply-To: <045.fbb1c0736cf81083c94a9ff0372ae621@haskell.org> References: <045.fbb1c0736cf81083c94a9ff0372ae621@haskell.org> Message-ID: <060.34a6482522d4e69db44f6645ff64773f@haskell.org> #8029: batch-mode recompilation checking sometimes fails -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | recompilation, batch-mode Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): For completeness, here is an example error message that mentions the package name `containers` for an ambiguous import with GHC 7.8.4: {{{ Test.hs:5:14: Ambiguous occurrence ?fromList? It could refer to either ?Data.Map.fromList?, imported from ?Data.Map? at Test.hs:2:1-15 (and originally defined at Data/Map.hs:2:1-8) or ?Data.Map.fromList?, imported from ?Data.Map? at Test.hs:3:1-28 (and originally defined in ?containers-0.5.5.1:Data.Map.Base?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 22:51:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 22:51:09 -0000 Subject: [GHC] #8872: hsc cast size warnings on 32-bit Linux In-Reply-To: <047.be22991936f471049817609a4b1ea4f2@haskell.org> References: <047.be22991936f471049817609a4b1ea4f2@haskell.org> Message-ID: <062.e5f1b1e00791ef94facc0fe3d99e3fb4@haskell.org> #8872: hsc cast size warnings on 32-bit Linux -------------------------------------+------------------------------ Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------ Changes (by thomie): * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 23:02:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 23:02:48 -0000 Subject: [GHC] #8877: "if this code is reached, the program will abort" in unregisterised build In-Reply-To: <046.60053a1b01344ea9a41702e5732d6278@haskell.org> References: <046.60053a1b01344ea9a41702e5732d6278@haskell.org> Message-ID: <061.16fd694a956ad0830625d93724c1c268@haskell.org> #8877: "if this code is reached, the program will abort" in unregisterised build -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8857 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: slyfox (added) * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: This should be fixed, thanks to the following commits: In commit 78863edbb0751f5c9694ea10c6132a87cfd0ee10: {{{ Author: Sergei Trofimovich <> Date: Wed Aug 27 22:20:33 2014 +0300 Revert "disable shared libs on sparc (linux/solaris) (fixes #8857)" This reverts commit 623883f1ed0ee11cc925c4590fb09565403fd231. The commit a93ab43ab5f40cadbedea2f6342b93c245e91434 driver: pass '-fPIC' option to assembler as well fixes shared libraries on sparc at least on linux. Properly fixes Issue #8857 Signed-off-by: Sergei Trofimovich }}} In commit fa31e8f4a0f853848d96549a429083941877bf8d: {{{ Author: Sergei Trofimovich <> Date: Sun Dec 14 14:30:12 2014 +0000 powerpc: fix and enable shared libraries by default on linux Summary: And fix things all the way down to it. Namely: - remove 'r30' from free registers, it's an .LCTOC1 register for gcc. generated .plt stubs expect it to be initialised. - fix PicBase computation, which originally forgot to use 'tmp' reg in 'initializePicBase_ppc.fetchPC' - mark 'ForeighTarget's as implicitly using 'PicBase' register (see comment for details) - add 64-bit MO_Sub and test on alloclimit3/4 regtests - fix dynamic label offsets to match with .LCTOC1 offset Signed-off-by: Sergei Trofimovich Test Plan: validate passes equal amount of vanilla/dyn tests Reviewers: simonmar, erikd, austin Reviewed By: erikd, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D560 GHC Trac Issues: #8024, #9831 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 23:07:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 23:07:03 -0000 Subject: [GHC] #7930: Nested STM Invariants are lost In-Reply-To: <048.13ce218649616d55ea8d6d48035a1772@haskell.org> References: <048.13ce218649616d55ea8d6d48035a1772@haskell.org> Message-ID: <063.c0becefff254be4224214900f64204ef@haskell.org> #7930: Nested STM Invariants are lost -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: fryguybob Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: STM Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 23:21:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 23:21:26 -0000 Subject: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" In-Reply-To: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> References: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> Message-ID: <057.1a201d314b2fc90af66c6e9969bb3c59@haskell.org> #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: GHC API => Build System Comment: Theres' a TODO in `includes/ghc.mk` about this: {{{ # Header files built from the configure script's findings # # XXX: these should go in includes/dist/build? includes_H_CONFIG = includes/ghcautoconf.h includes_H_PLATFORM = includes/ghcplatform.h includes_H_VERSION = includes/ghcversion.h }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 23:46:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 23:46:24 -0000 Subject: [GHC] #9041: NCG generates slow loop code In-Reply-To: <042.98aca4c930785f21daf56def917ee27d@haskell.org> References: <042.98aca4c930785f21daf56def917ee27d@haskell.org> Message-ID: <057.22be7deeed8cfc15be527cdbcdd82dcb@haskell.org> #9041: NCG generates slow loop code -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: Compile-time performance bug => Runtime performance bug Comment: Grouping this with the other 165 [https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Runtime+performance+bug runtime performance bugs]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 24 23:57:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Mar 2015 23:57:10 -0000 Subject: [GHC] #9780: dep_orphs in Dependencies redundantly records type family orphans In-Reply-To: <045.8bb223632e43c545d555772c72d364f6@haskell.org> References: <045.8bb223632e43c545d555772c72d364f6@haskell.org> Message-ID: <060.b14fe40984b4668b2e022a2b9b3d4bb2@haskell.org> #9780: dep_orphs in Dependencies redundantly records type family orphans -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 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 Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: You updated that comment in commit 4c834fdddf4d44d12039da4d6a2c63a660975b95: {{{ Author: Edward Z. Yang <> Date: Mon Nov 17 21:23:52 2014 -0800 Filter instance visibility based on set of visible orphans, fixes #2182. Summary: Amazingly, the fix for this very old bug is quite simple: when type- checking, maintain a set of "visible orphan modules" based on the orphans list of modules which we explicitly imported. When we import an instance and it is an orphan, we check if it is in the visible modules set, and if not, ignore it. A little bit of refactoring for when orphan-hood is calculated happens so that we always know if an instance is an orphan or not. For GHCi, we preinitialize the visible modules set based on the list of interactive imports which are active. Future work: Cache the visible orphan modules set for GHCi, rather than recomputing it every type-checking round. (But it's tricky what to do when you /remove/ a module: you need a data structure a little more complicated than just a set of modules.) Signed-off-by: Edward Z. Yang Test Plan: new tests and validate Reviewers: simonpj, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D488 GHC Trac Issues: #2182 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 00:49:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 00:49:17 -0000 Subject: [GHC] #9780: dep_orphs in Dependencies redundantly records type family orphans In-Reply-To: <045.8bb223632e43c545d555772c72d364f6@haskell.org> References: <045.8bb223632e43c545d555772c72d364f6@haskell.org> Message-ID: <060.86eee7a20ae76eab1859c26bc00eb4ab@haskell.org> #9780: dep_orphs in Dependencies redundantly records type family orphans -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => Comment: I now realize this bug report is not just about changing the invalid comment, but also about performing the optimization mentioned in the title. In `main/HscTypes.hs`: {{{ , dep_orphs :: [Module] -- ^ Transitive closure of orphan modules (whether -- home or external pkg). -- -- (Possible optimization: don't include family -- instance orphans as they are anyway included in -- 'dep_finsts'. But then be careful about code -- which relies on dep_orphs having the complete list!) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 01:08:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 01:08:27 -0000 Subject: [GHC] #4295: Review higher-rank and impredicative types In-Reply-To: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> References: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> Message-ID: <061.05e93cf3ff8202427be3c879d60cac25@haskell.org> #4295: Review higher-rank and impredicative types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.12.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => task * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 01:09:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 01:09:52 -0000 Subject: [GHC] #9420: Impredicative type instantiation without -XImpredicativeTypes In-Reply-To: <047.6ad1d8a60b0767b72a70d900459f9391@haskell.org> References: <047.6ad1d8a60b0767b72a70d900459f9391@haskell.org> Message-ID: <062.f015c36ee9ad83025338d7b442edcfdf@haskell.org> #9420: Impredicative type instantiation without -XImpredicativeTypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 01:14:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 01:14:10 -0000 Subject: [GHC] #9708: Type inference non-determinism due to improvement In-Reply-To: <046.b82d37e7450cce9a05553877e957cde0@haskell.org> References: <046.b82d37e7450cce9a05553877e957cde0@haskell.org> Message-ID: <061.afa22dc580a61f2a7b54fea4060d6e85@haskell.org> #9708: Type inference non-determinism due to improvement -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 04:39:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 04:39:32 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) Message-ID: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now Monoid is defined in GHC.Base; We can define a reasonable Monad instance for `(,) w`, as a writer monad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 04:43:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 04:43:18 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.5035b8e1d1393b0295931d65db40146f@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by fumieval): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 04:50:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 04:50:29 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.ed9ab2a82ca6b4964b833d2fe4d499be@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by fumieval): * cc: core-libraries-committee@? (added) * component: libraries/base => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 05:02:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 05:02:17 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally In-Reply-To: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> References: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> Message-ID: <063.2e0ce59308a3bf0d179c5dfce1069dd8@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10188 | -------------------------------------+------------------------------------- Changes (by Kinokkory): * related: => #10188 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 05:02:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 05:02:36 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.27b5f7e97a0ba0a6d58d0bd4f288c1d0@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10189 | -------------------------------------+------------------------------------- Changes (by Kinokkory): * related: => #10189 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 05:53:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 05:53:27 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.22cac6afc6a0007d05e7575ada3f9161@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): No objection from me. This has passed the libraries@ proposal process on at least 2 separate occasions in recent memory, but had been blocked by the fact that Monoid wasn't in scope where the Monad class was defined. We have the compatible Applicative instance. I had honestly thought we already had the instance in 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 06:05:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 06:05:33 -0000 Subject: [GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel In-Reply-To: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> References: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> Message-ID: <059.5e8cd18652061dc9ababb1bdcbd6946c@haskell.org> #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): This is very strange! The failures I was getting was with `BuildFlavour = quick-llvm` but when I changed that to `BuildFlavour = perf-llvm` it build to completion. Currently rebuilding with `quick-llvm` to make sure that's what it is and not the couple of patches I just pulled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 06:23:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 06:23:32 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.c240db731798820f22edd18edbb09671@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): I have no objection to this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 07:14:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 07:14:26 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.d8fc6fa33362d605a63e5f00dbd5757a@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: fumieval Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * owner: => fumieval * type: bug => feature request * version: 7.8.4 => * component: Core Libraries => libraries/base * milestone: => 7.12.1 Comment: Replying to [comment:1 fumieval]: Re your patch, the implementation LGTM, but the meta-information needs improvement: - missing a `libraries/base/changelog.md` entry - commit message needs to reference `#10190` - commit message should contain link(s) to the threads which proposed this addition (and passed) Please also consider using Phabricator, as then we also get validation via the build-bot that your patch doesn't need additional tweaks somewhere (e.g. in the testsuite) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 08:09:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 08:09:50 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.0f3badf268b40c63feae92d7ef82cc24@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: fumieval Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fumieval): Sorry, I couldn't find the thread which proposed this instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 09:40:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 09:40:37 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.f0f0ea7b7e6c1422c0acd6c61101d7b9@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: fumieval Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Here are two of the proposals that went through the libraries@ process over the years on the topic: * https://mail.haskell.org/pipermail/libraries/2011-November/017153.html * https://mail.haskell.org/pipermail/libraries/2013-July/020446.html My google-fu is failing me when it comes to finding the rest quickly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 12:19:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 12:19:17 -0000 Subject: [GHC] #7567: invalidateModSummaryCache throws exception if ms_hs_date is 0 In-Reply-To: <044.528a24a412eb29535dc4aa70b74720f6@haskell.org> References: <044.528a24a412eb29535dc4aa70b74720f6@haskell.org> Message-ID: <059.578529003fa73c9cef1b1682fb62b366@haskell.org> #7567: invalidateModSummaryCache throws exception if ms_hs_date is 0 -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | thoughtpolice Priority: high | Status: infoneeded Component: Compiler | Milestone: 7.12.1 Resolution: | Version: 7.6.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Edsko: I am having trouble reproducing your issue. The file `main/GHC.hs` uses `Data.Time` from the `time` package, and has so from the beginning. `Time.toClockTime` is a function from the `old- time` package, which GHC doesn't use. How can it throw an error? Also if I call `addUTCTime (-1)` on `UTCTime (ModifiedJulianDay 0) (secondsToDiffTime 0)`, and force its result, nothing bad happens. Can you give me instructions how to trigger the bug. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 12:31:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 12:31:09 -0000 Subject: [GHC] #8034: Missing ambiguity test for class methods In-Reply-To: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> References: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> Message-ID: <061.5f37e3460b6ce23518c4df338081a7a5@haskell.org> #8034: Missing ambiguity test for class methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 13:09:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 13:09:37 -0000 Subject: [GHC] #10191: Interactive linker crash when partially applying seq# Message-ID: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> #10191: Interactive linker crash when partially applying seq# -----------------------------------------+------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.4-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- Consider the following commands: {{{#!hs :set -XMagicHash import GHC.IO import GHC.Prim IO (seq# ()) }}} When the last statement is run in GHCi, the following error message is displayed: {{{ ByteCodeLink.lookupCE(primop) During interactive linking, GHCi couldn't find the following symbol: ghczmprim_GHCziPrimopWrappers_seqzh_closure 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 }}} The expression works if I eta-unreduce the `seq#` call: `IO (\x -> seq# () x)`. The problem seems to be exclusive to GHCi: if you put that expression in a file, it works fine when compiled by GHC, and even GHCi works fine when using the resulting `.o` file. When there's no `.o` GHCi still crashes, and eta-unreduction doesn't help anymore (something to with optimizations I guess). I can also reproduce this on the Linux-x86 architecture. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 13:18:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 13:18:50 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.d1d5b3318741de5e26da2ec25a74251e@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: fumieval Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): I'll take it from here, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 13:51:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 13:51:21 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.c0dbfe24040089cb1ef488bdf292d96c@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: fumieval Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9db005a444722e31aca1956b058e069bcf3cacbd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9db005a444722e31aca1956b058e069bcf3cacbd" Add Monad instance for `((,) a)` (#10190) This was proposed a couple of times in the past, e.g. - https://mail.haskell.org/pipermail/libraries/2011-November/017153.html - https://mail.haskell.org/pipermail/libraries/2013-July/020446.html but its implementation had been blocked by the fact that `Monoid` wasn't in scope where the `Monad` class was defined. Since the AMP/FTP restructuring this is no longer the case. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 14:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 14:11:33 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.2707f776713973d04f07ee897302cb07@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: fumieval Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 14:11:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 14:11:56 -0000 Subject: [GHC] #10190: Add a Monad instance for ((,) w) In-Reply-To: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> References: <047.9626287bddb03e177c89ebea4a98f212@haskell.org> Message-ID: <062.866679d34bf9dc87e1885d1a9fc1e16d@haskell.org> #10190: Add a Monad instance for ((,) w) -------------------------------------+------------------------------------- Reporter: fumieval | Owner: fumieval Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 25 21:12:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Mar 2015 21:12:57 -0000 Subject: [GHC] #10192: Template Haskell crashes when building yesod-core package Message-ID: <049.3323838842ade82bcaef02c773453e2b@haskell.org> #10192: Template Haskell crashes when building yesod-core package -------------------------------------+------------------------------------- Reporter: DanielDiaz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is the output when trying to install yesod-core in a sandbox: {{{ Configuring yesod-core-1.4.8.3... Building yesod-core-1.4.8.3... Preprocessing library yesod-core-1.4.8.3... [ 1 of 31] Compiling Yesod.Routes.TH.Types ( Yesod/Routes/TH/Types.hs, dist/dist-sandbox-d1f72a97/build/Yesod/Routes/TH/Types.o ) [ 2 of 31] Compiling Yesod.Routes.TH.Dispatch ( Yesod/Routes/TH/Dispatch.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Routes/TH/Dispatch.o ) [ 3 of 31] Compiling Yesod.Routes.Overlap ( Yesod/Routes/Overlap.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Routes/Overlap.o ) [ 4 of 31] Compiling Yesod.Core.TypeCache ( Yesod/Core/TypeCache.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Core/TypeCache.o ) [ 5 of 31] Compiling Yesod.Routes.Class ( Yesod/Routes/Class.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Routes/Class.o ) [ 6 of 31] Compiling Yesod.Routes.TH.RenderRoute ( Yesod/Routes/TH/RenderRoute.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Routes/TH/RenderRoute.o ) [ 7 of 31] Compiling Yesod.Routes.TH.ParseRoute ( Yesod/Routes/TH/ParseRoute.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Routes/TH/ParseRoute.o ) [ 8 of 31] Compiling Yesod.Routes.TH.RouteAttrs ( Yesod/Routes/TH/RouteAttrs.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Routes/TH/RouteAttrs.o ) [ 9 of 31] Compiling Yesod.Routes.TH ( Yesod/Routes/TH.hs, dist/dist- sandbox-d1f72a97/build/Yesod/Routes/TH.o ) [10 of 31] Compiling Yesod.Routes.Parse ( Yesod/Routes/Parse.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Routes/Parse.o ) [11 of 31] Compiling Paths_yesod_core ( dist/dist-sandbox- d1f72a97/build/autogen/Paths_yesod_core.hs, dist/dist-sandbox- d1f72a97/build/Paths_yesod_core.o ) [12 of 31] Compiling Yesod.Core.Internal.Util ( Yesod/Core/Internal/Util.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Internal/Util.o ) [13 of 31] Compiling Yesod.Core.Types ( Yesod/Core/Types.hs, dist/dist- sandbox-d1f72a97/build/Yesod/Core/Types.o ) [14 of 31] Compiling Yesod.Core.Class.Handler ( Yesod/Core/Class/Handler.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Class/Handler.o ) Yesod/Core/Class/Handler.hs:25:1: Warning: Module ?Control.Monad.Trans.Error? is deprecated: Use Control.Monad.Trans.Except instead Yesod/Core/Class/Handler.hs:56:11: Warning: In the use of type constructor or class ?Error? (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" Yesod/Core/Class/Handler.hs:56:54: Warning: In the use of type constructor or class ?ErrorT? (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" Yesod/Core/Class/Handler.hs:56:91: Warning: In the use of type constructor or class ?ErrorT? (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" Yesod/Core/Class/Handler.hs:79:11: Warning: In the use of type constructor or class ?Error? (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" Yesod/Core/Class/Handler.hs:79:52: Warning: In the use of type constructor or class ?ErrorT? (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" [15 of 31] Compiling Yesod.Core.Internal.Request ( Yesod/Core/Internal/Request.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Internal/Request.o ) [16 of 31] Compiling Yesod.Core.Internal.Session ( Yesod/Core/Internal/Session.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Internal/Session.o ) [17 of 31] Compiling Yesod.Core.Content ( Yesod/Core/Content.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Core/Content.o ) Yesod/Core/Content.hs:227:27: Warning: In the use of ?B.breakByte? (imported from Data.ByteString): Deprecated: "It is an internal function and should never have been exported. Use 'break (== x)' instead. (There are rewrite rules that handle this special case of 'break'.)" Yesod/Core/Content.hs:232:36: Warning: In the use of ?B.breakByte? (imported from Data.ByteString): Deprecated: "It is an internal function and should never have been exported. Use 'break (== x)' instead. (There are rewrite rules that handle this special case of 'break'.)" Yesod/Core/Content.hs:235:19: Warning: In the use of ?B.breakByte? (imported from Data.ByteString): Deprecated: "It is an internal function and should never have been exported. Use 'break (== x)' instead. (There are rewrite rules that handle this special case of 'break'.)" [18 of 31] Compiling Yesod.Core.Handler ( Yesod/Core/Handler.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Core/Handler.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.1.0 ... linking ... done. Loading package auto-update-0.1.2.1 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.6.0 ... linking ... done. Loading package text-1.2.0.4 ... linking ... done. Loading package blaze-builder-0.4.0.1 ... linking ... done. Loading package hashable-1.2.3.2 ... linking ... done. Loading package case-insensitive-1.2.0.4 ... linking ... done. Loading package containers-0.5.6.3 ... linking ... done. Loading package scientific-0.3.3.8 ... linking ... done. Loading package attoparsec-0.12.1.3 ... linking ... done. Loading package http-date-0.0.6 ... linking ... done. Loading package http-types-0.8.6 ... linking ... done. Loading package appar-0.1.4 ... linking ... done. Loading package byteorder-1.0.4 ... linking ... done. Loading package time-1.5.0.1 ... linking ... done. Loading package unix-2.7.1.0 ... linking ... done. Loading package network-2.6.0.2 ... linking ... done. Loading package iproute-1.3.2 ... linking ... done. Loading package simple-sendfile-0.2.18 ... linking ... done. Loading package filepath-1.4.0.0 ... linking ... done. Loading package directory-1.2.2.0 ... linking ... done. Loading package process-1.2.3.0 ... linking ... done. Loading package random-1.1 ... linking ... done. Loading package stm-2.4.4 ... linking ... done. Loading package transformers-0.4.3.0 ... linking ... done. Loading package zlib-0.5.4.2 ... linking ... done. Loading package streaming-commons-0.1.10.0 ... linking ... done. Loading package unix-compat-0.4.1.4 ... linking ... done. Loading package unordered-containers-0.2.5.1 ... linking ... done. Loading package vault-0.3.0.4 ... linking ... done. Loading package nats-1 ... linking ... done. Loading package semigroups-0.16.2.2 ... linking ... done. Loading package void-0.7 ... linking ... done. Loading package wai-3.0.2.3 ... linking ... done. Loading package warp-3.0.10 ... linking ... done. Loading package ansi-terminal-0.6.2.1 ... linking ... done. Loading package base64-bytestring-1.0.0.1 ... linking ... done. Loading package data-default-class-0.0.1 ... linking ... done. Loading package bytestring-builder-0.10.4.1.2 ... linking ... done. Loading package fast-logger-2.3.0 ... linking ... done. Loading package transformers-compat-0.4.0.4 ... linking ... done. Loading package transformers-base-0.4.4 ... linking ... done. Loading package monad-control-1.0.0.4 ... linking ... done. Loading package lifted-base-0.2.3.6 ... linking ... done. Loading package old-locale-1.0.0.7 ... linking ... done. Loading package mtl-2.2.1 ... linking ... done. Loading package exceptions-0.8.0.2 ... linking ... done. Loading package mmorph-1.0.4 ... linking ... done. Loading package resourcet-1.1.4.1 ... linking ... done. Loading package stringsearch-0.3.6.5 ... linking ... done. Loading package easy-file-0.2.0 ... linking ... done. Loading package binary-0.7.4.0 ... linking ... done. Loading package old-time-1.1.0.3 ... linking ... done. Loading package unix-time-0.3.5 ... linking ... done. Loading package wai-logger-2.2.3 ... linking ... done. Loading package word8-0.1.2 ... linking ... done. Loading package wai-extra-3.0.4.6 ... linking ... done. Loading package dlist-0.7.1.1 ... linking ... done. Loading package syb-0.4.4 ... linking ... done. Loading package pretty-1.1.3.2 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package primitive-0.5.4.0 ... linking ... done. Loading package vector-0.10.12.2 ... linking ... done. Loading package aeson-0.8.0.2 ... linking ... done. Loading package blaze-markup-0.7.0.2 ... linking ... done. Loading package blaze-html-0.8.0.2 ... linking ... done. Loading package parsec-3.1.9 ... linking ... done. Loading package system-filepath-0.4.13.2 ... linking ... done. Loading package system-fileio-0.3.16.1 ... linking ... done. Loading package shakespeare-2.0.4.1 ... linking ... done. Loading package safe-0.3.8 ... linking ... done. Loading package path-pieces-0.2.0 ... linking ... done. Loading package mwc-random-0.13.3.0 ... linking ... done. Loading package conduit-1.2.4 ... linking ... done. Loading package conduit-extra-1.1.7.1 ... linking ... done. Loading package monad-loops-0.4.2.1 ... linking ... done. Loading package stm-chans-3.0.0.2 ... linking ... done. Loading package monad-logger-0.3.13.1 ... linking ... done. Loading package data-default-instances-base-0.0.1 ... linking ... done. Loading package data-default-instances-containers-0.0.1 ... linking ... done. Loading package data-default-instances-dlist-0.0.1 ... linking ... done. Loading package data-default-instances-old-locale-0.0.1 ... linking ... done. Loading package data-default-0.5.3 ... linking ... done. Loading package cookie-0.4.1.4 ... linking ... done. Loading package cereal-0.4.1.1 ... linking ... done. Loading package byteable-0.1.1 ... linking ... done. Loading package securemem-0.1.7 ... linking ... done. Loading package crypto-cipher-types-0.0.9 ... linking ... done. Loading package cipher-aes-0.2.10 ... linking ... done. Loading package crypto-random-0.0.9 ... linking ... done. Loading package cprng-aes-0.6.1 ... linking ... done. Loading package entropy-0.3.6 ... linking ... done. Loading package tagged-0.7.3 ... linking ... done. Loading package crypto-api-0.13.2 ... linking ... done. Loading package setenv-0.1.1.3 ... linking ... done. Loading package skein-1.0.9.2 ... linking ... done. Loading package clientsession-0.9.1.1 ... linking ... done. [19 of 31] Compiling Yesod.Core.Widget ( Yesod/Core/Widget.hs, dist/dist- sandbox-d1f72a97/build/Yesod/Core/Widget.o ) [20 of 31] Compiling Yesod.Core.Class.Breadcrumbs ( Yesod/Core/Class/Breadcrumbs.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Class/Breadcrumbs.o ) [21 of 31] Compiling Yesod.Core.Class.Yesod ( Yesod/Core/Class/Yesod.hs, dist/dist-sandbox-d1f72a97/build/Yesod/Core/Class/Yesod.o ) [22 of 31] Compiling Yesod.Core.Json ( Yesod/Core/Json.hs, dist/dist- sandbox-d1f72a97/build/Yesod/Core/Json.o ) [23 of 31] Compiling Yesod.Core.Internal.Response ( Yesod/Core/Internal/Response.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Internal/Response.o ) [24 of 31] Compiling Yesod.Core.Internal.Run ( Yesod/Core/Internal/Run.hs, dist/dist-sandbox-d1f72a97/build/Yesod/Core/Internal/Run.o ) ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: templatezmhaskell_LanguageziHaskellziTHziSyntax_zdfMonadQzuzdczgzgze_closure 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 }}} It's in a fresh installation of GHC-7.8.4, using cabal-install-1.22.2.0. It is worth noting that this works: {{{ cabal sandbox init cabal install yesod-core }}} But this does not: {{{ cabal sandbox init cabal install yesod-core --upgrade-dependencies --force-reinstalls }}} The context where I ran into this problem uses {{{--upgrade- dependencies}}}, and installs yesod-core as a dependency. Let me know if you need more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 03:54:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 03:54:03 -0000 Subject: [GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel In-Reply-To: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> References: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> Message-ID: <059.ae81a935abbe5a865aedd034521bccdd@haskell.org> #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Confirmed. On Arm64, building as `quick-llvm` results in a `ghc-stage2` that segfaults building `libraries/parallel` but building `perf-llvm` works fine. On amd64, both `quick-llvm` and `perf-llvm` work fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 06:10:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 06:10:33 -0000 Subject: [GHC] #10192: Template Haskell crashes when building yesod-core package In-Reply-To: <049.3323838842ade82bcaef02c773453e2b@haskell.org> References: <049.3323838842ade82bcaef02c773453e2b@haskell.org> Message-ID: <064.3ae491be52445af5de2778d24bbda1e6@haskell.org> #10192: Template Haskell crashes when building yesod-core package -------------------------------------+------------------------------------- Reporter: DanielDiaz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): Seems like the bug is that it's forcing a new installation of template- haskell, which isn't working. I'd recommend adding a constraint requiring `template-haskell installed` and see if that fixes your problem. I would definitely advise against such an upgrade. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 06:33:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 06:33:40 -0000 Subject: [GHC] #10192: Template Haskell crashes when building yesod-core package In-Reply-To: <049.3323838842ade82bcaef02c773453e2b@haskell.org> References: <049.3323838842ade82bcaef02c773453e2b@haskell.org> Message-ID: <064.0b0cd2b98cfe6db990843a41303812e5@haskell.org> #10192: Template Haskell crashes when building yesod-core package -------------------------------------+------------------------------------- Reporter: DanielDiaz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by DanielDiaz): Replying to [comment:1 snoyberg]: > Seems like the bug is that it's forcing a new installation of template- haskell, which isn't working. I'd recommend adding a constraint requiring `template-haskell installed` and see if that fixes your problem. I would definitely advise against such an upgrade. That indeed worked. I added "constraint: template-haskell installed" to my {{{~/.cabal/config}}} file and I built yesod-core successfully. I must admit I didn't knew about the constraint on installed versions. If it's the case that template-haskell should not be upgraded... Shouldn't this constraint be there by default? Or somehow enforced by any other means? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 06:34:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 06:34:47 -0000 Subject: [GHC] #10192: Template Haskell crashes when building yesod-core package In-Reply-To: <049.3323838842ade82bcaef02c773453e2b@haskell.org> References: <049.3323838842ade82bcaef02c773453e2b@haskell.org> Message-ID: <064.ac5f2e808766527d19cf42a0bedfac28@haskell.org> #10192: Template Haskell crashes when building yesod-core package -------------------------------------+------------------------------------- Reporter: DanielDiaz | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by DanielDiaz): * priority: normal => low * failure: None/Unknown => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 12:23:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 12:23:16 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.2dea543bb2a922edc7492c71d658d391@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T10177 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Actually I really don't think this code should work. It should be {{{ instance (Typeable n, Typeable a) => C (V n a) }}} Otherwise there is an overlap between the given `(Typeable (V n))` and the built-in instance for `Typeable (V n a)`. Making the code given here work is very fragile, and might depend on solve order. I vote that should fail. Any dissenters? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 13:12:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 13:12:33 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally In-Reply-To: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> References: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> Message-ID: <063.bc5de1be671c83e120cd87b94fc3f780@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10188 | -------------------------------------+------------------------------------- Comment (by goldfire): The Template Haskell quotes are unaffected. They appear only in terms, which has a separate parser. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 13:20:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 13:20:56 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.7c40ae1db9eec840a4f823ae8e9ec502@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T10177 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): What about this? {{{ instance (Typeable a, Typeable b) => C (a b) }}} That looks good to me. But what you have above is just a simple substitution on my instance, so I think it should be good. Can the `Typeable` solver just immediately decompose `Typeable (V n)` to `Typeable n`? Is there a threat that the overlapping instances are semantically different? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 13:30:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 13:30:24 -0000 Subject: [GHC] #8030: FlexibleContexts PolyKinds Type Families bug In-Reply-To: <042.54ee6c0fdb0fba6e2b8357f8ae0511fe@haskell.org> References: <042.54ee6c0fdb0fba6e2b8357f8ae0511fe@haskell.org> Message-ID: <057.fef135ed187aac91c44423c201619081@haskell.org> #8030: FlexibleContexts PolyKinds Type Families bug -------------------------------------+------------------------------------- Reporter: wvv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8034 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #8034 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 13:55:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 13:55:40 -0000 Subject: [GHC] #10192: Template Haskell crashes when building yesod-core package In-Reply-To: <049.3323838842ade82bcaef02c773453e2b@haskell.org> References: <049.3323838842ade82bcaef02c773453e2b@haskell.org> Message-ID: <064.2c3cbd0b29af47c67d6c0eb8c50b9709@haskell.org> #10192: Template Haskell crashes when building yesod-core package -------------------------------------+------------------------------------- Reporter: DanielDiaz | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by refold): I think that this is (sort of) fixed in GHC 7.10+ because `template- haskell` no longer depends on `containers`. It may still be worthwhile looking into why reinstalling the same version of `template-haskell` (2.9.0.0) breaks things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 13:57:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 13:57:06 -0000 Subject: [GHC] #8034: Missing ambiguity test for class methods In-Reply-To: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> References: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> Message-ID: <061.49acc45bd7b2490743b9c48ffae3b2d7@haskell.org> #8034: Missing ambiguity test for class methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): I looked at the code today to see if I can fix this together with #6018. A quick diagnosis is that the type of class operation is stripped from the foralls and thetas so that only tau remains (in Simon's example the type `foo :: forall (k :: BOX) (a :: k). C a => F a -> F a` is stripped to `F a -> F a`). This tau is passed to ambiguity check but since there are no quantified variables the ambiguity check always succeeds. I wonder what would be the right strategy here: 1. In `TcTyClsDecls.checkValidClass` call `checkValidType` (inside `check_op`) with some type other than `tau`. I tried a quick hack to add the forall variables back to tau (ie. the original type of class operation is stripped only from thetas) but there are some corner cases where this does not work. 2. Modify the first case of `TcValidity.check_type` to look for type variables under type family applications even if these variables are not quantified. I'm not sure which of these two is the right way of fixing this so I didn't try too hard to implement any of these. If anyone with more knowledge can hint me which of these to would be the right way of fixing this I think I should be able to write a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 14:20:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 14:20:52 -0000 Subject: [GHC] #8034: Missing ambiguity test for class methods In-Reply-To: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> References: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> Message-ID: <061.0d60f08615a5ba435dae17c610b96b9b@haskell.org> #8034: Missing ambiguity test for class methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): This is fixed in HEAD already, isn't it? The example from the description gives an ambiguity error at least. See the following commit for details: In f66e0e695b0377c469fbe877d4850fc0ebca2010: {{{ Author: Simon Peyton Jones <> Date: Wed Mar 4 11:59:47 2015 +0000 A raft of small changes associated with -XConstrainedClassMethods See Trac #7854. Specifically: * Major clean up and simplification of check_op in checkValidClass; specifically - use checkValidType on the entire method-selector type to detect ambiguity - put a specific test for -XConstrainedClassMethods * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses (a bit ad-hoc but see #7854), and document in the user manual. * Do the checkAmbiguity test just once in TcValidity.checkValidType, rather than repeatedly at every level. See Note [When to call checkAmbiguity] * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous. (It's a rather magic function.) * Improve location info for check_op in checkValidClass * Update quite a few tests, which had genuinely-ambiguous class method signatures. Some I fixed by making them unambiguous; some by adding -XAllowAmbiguousTypes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 14:29:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 14:29:44 -0000 Subject: [GHC] #8030: FlexibleContexts PolyKinds Type Families bug In-Reply-To: <042.54ee6c0fdb0fba6e2b8357f8ae0511fe@haskell.org> References: <042.54ee6c0fdb0fba6e2b8357f8ae0511fe@haskell.org> Message-ID: <057.c9f06c9c34e244caaa47a2af03a45f73@haskell.org> #8030: FlexibleContexts PolyKinds Type Families bug -------------------------------------+------------------------------------- Reporter: wvv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8034 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Fixed in HEAD, probably in commit f66e0e695b0377c469fbe877d4850fc0ebca2010: {{{ Author: Simon Peyton Jones <> Date: Wed Mar 4 11:59:47 2015 +0000 A raft of small changes associated with -XConstrainedClassMethods See Trac #7854. Specifically: * Major clean up and simplification of check_op in checkValidClass; specifically - use checkValidType on the entire method-selector type to detect ambiguity - put a specific test for -XConstrainedClassMethods * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses (a bit ad-hoc but see #7854), and document in the user manual. * Do the checkAmbiguity test just once in TcValidity.checkValidType, rather than repeatedly at every level. See Note [When to call checkAmbiguity] * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous. (It's a rather magic function.) * Improve location info for check_op in checkValidClass * Update quite a few tests, which had genuinely-ambiguous class method signatures. Some I fixed by making them unambiguous; some by adding -XAllowAmbiguousTypes }}} Now always shows the same ambiguity error. Needs a regression test before closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 14:41:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 14:41:31 -0000 Subject: [GHC] #8034: Missing ambiguity test for class methods In-Reply-To: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> References: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> Message-ID: <061.a3b2bb16128ef53fcbd36be1ff8e5c80@haskell.org> #8034: Missing ambiguity test for class methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Perhaps. I haven't checked HEAD, only my branch, which was not rebased on HEAD for the last couple of weeks. If this is fixed we probably need a regression test before we close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 15:02:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 15:02:02 -0000 Subject: [GHC] #10193: TypeRep Show instance doesn't add parens around type operators Message-ID: <050.ff6cff2e03c64787c90e72c6c5c4a299@haskell.org> #10193: TypeRep Show instance doesn't add parens around type operators -------------------------------------+------------------------------------- Reporter: | Owner: pawel.nowak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc3 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Incorrect result Keywords: | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code {{{#!hs {-# LANGUAGE AutoDeriveTypeable #-} {-# LANGUAGE TypeOperators #-} import Data.Typeable data a :*: b = Pair a b main = print (typeOf (Pair 'a' 'b')) }}} prints {{{#!hs :*: Char Char }}} which is not valid Haskell. I belive it should print {{{#!hs (:*:) Char Char }}} In my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation: {{{#!hs let type_str = show $ Data.Typeable.typeOf wit ... let expr_typesig = concat [parens e, " :: ", type_str] }}} What results in a parse error. I can write a patch if someone confirms that's the desired behavior and doesn't break anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 15:14:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 15:14:14 -0000 Subject: [GHC] #10193: TypeRep Show instance doesn't add parens around type operators In-Reply-To: <050.ff6cff2e03c64787c90e72c6c5c4a299@haskell.org> References: <050.ff6cff2e03c64787c90e72c6c5c4a299@haskell.org> Message-ID: <065.41f4aa19cafc1bc246cd75224fa4d63c@haskell.org> #10193: TypeRep Show instance doesn't add parens around type operators -------------------------------------+------------------------------------- Reporter: pawel.nowak | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.12.1 Comment: Fwiw, GHCi does the right thing already: {{{ > :t Pair 'a' 'b' Pair 'a' 'b' :: Char :*: Char }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 20:19:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 20:19:05 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? Message-ID: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: | invalid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program compiles: {{{ {-# LANGUAGE RankNTypes #-} module TestRN1 where type X = forall a . a comp :: (X -> c) -> (a -> X) -> (a -> c) comp = (.) }}} But this one fails: {{{ {-# LANGUAGE RankNTypes #-} module TestRN2 where comp :: ((forall a . a) -> c) -> (a -> (forall a . a)) -> (a -> c) comp = (.) }}} Error: {{{ Cannot instantiate unification variable ?b0? with a type involving foralls: forall a1. a1 Perhaps you want ImpredicativeTypes In the expression: (.) In an equation for ?comp?: comp = (.) }}} I would expect both to fail. Both seem to rely on impredicative types. I wouldn't expect expansion of a type synonym to make a difference between a type-checking program and one that does not typecheck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 20:20:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 20:20:28 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.eef007bf6818edecacf6099ed40c2c82@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 21:22:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 21:22:30 -0000 Subject: [GHC] #10191: Interactive linker crash when partially applying seq# In-Reply-To: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> References: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> Message-ID: <059.13b773871076e9258986dbe38e919685@haskell.org> #10191: Interactive linker crash when partially applying seq# -------------------------------+----------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.4-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): `seq#` and some other primops don't get wrappers due to this filter in genprimopcode: {{{ dodgy spec = name spec `elem` [-- C code generator can't handle these "seq#", "tagToEnum#", -- not interested in parallel support "par#", "parGlobal#", "parLocal#", "parAt#", "parAtAbs#", "parAtRel#", "parAtForNow#" ] }}} I'm not sure entirely what this is all about, but since the code is 14 years old I'm just going to try deleting it and seeing if anything goes wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 26 21:53:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Mar 2015 21:53:46 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.d30fb9541614915bbe9d0d1d09ee5655@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T10177 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by diatchki): I don't think that there is anything wrong here, so I think that we should accept the program. The (new, now merged) `Typeable` solver does exactly what Richard says. The instance for `Typeable (f a)` has to be computed from the evidence for the types `f` and `a`. If that was not the case, we'd get some very odd behavior depending on how type variables get instantiated. Now, if `f` happened to be a concrete type (e.g., like `V n`), then we can reduce further, but if we happen to already have a solution for `V n`, we don't have to reduce any further---after all, ''that'' solution must have been built by the internal typeable solver in the first place. Note that the actual `TypeRep`s are built by always applying the constructor to all arguments: see the comment on `mkAppTy` in `Data.Typeable.Internal`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 01:09:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 01:09:54 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs Message-ID: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Here's a relatively short piece of code that doesn't compile: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, GADTs, ConstraintKinds, KindSignatures, FlexibleInstances #-} module Foo where import GHC.Exts data Foo m zp r'q = Foo zp data Dict :: Constraint -> * where Dict :: a => Dict a type family BarFamily a b :: Bool class Bar m m' instance (BarFamily m m' ~ 'True) => Bar m m' magic :: (Bar m m') => c m zp -> Foo m zp (c m' zq) magic = error "" getDict :: a -> Dict (Num a) getDict _ = error "" fromScalar :: r -> c m r fromScalar = error "" foo :: (Bar m m') => c m zp -> Foo m zp (c m' zq) -> Foo m zp (c m' zq) foo b (Foo sc) = let scinv = fromScalar sc in case getDict scinv of Dict -> magic $ scinv * b }}} GHC complains that it {{{ cannot deduce (BarFamily m m' ~ 'True) arising from a use of `magic` }}} in the definition of `foo`. Of course this is silly: `magic` requires `Bar m m'`, which is supplied as a constraint to `foo`. So GHC is forgetting about the constraint on `foo` and instead trying to satisfy the generic instance of `Bar` which has the constraint `(BarFamily m m' ~ 'True)`. I've found no less than six different ways to poke this code to make it compile, and some of them seem to reveal dangerous/unexpected behavior. The following are all deltas from the original code above and result in compiling code. 1. Add `ScopedTypeVariables` and give `scinv` an explicit signature: {{{ let scinv = fromScalar sc :: c m z in ... }}} I'm not sure why this would make GHC suddenly realize that it already has the constraint `Bar m m'`, but it seems to. (What it definitely does *not* do is result in a `BarFamily m m' ~ 'True` constraint.) 2. Remove the instance for `Bar`. This seems highly suspicious: the presence (or lack thereof) of an instance changes how GHC resolves the constraint in `foo`. 3. Change the constraint on `foo` to `BarFamily m m' ~ 'True`. In this case, GHC does *not* forget the constraint on `foo` and successfully uses it to satisfy the instance of `Bar`. Why does GHC forget about `Bar m m'` but not `BarFamily m m' ~ 'True`? 4. Add the superclass constraint `BarFamily m m' ~ 'True` to class `Bar`. Adding this constraint either makes GHC find the `Bar m m'` constraint on `foo` or, even more bizarrely, GHC still forgets about `Bar m m'` but manages to get the superclass constraint from `Bar m m'` and uses it to satisfy the instance. 5. Add `PolyKinds`. Not sure why this would affect anything. 6. Change the signature of `fromScalar` to `r -> s`. Not sure why this would affect anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 04:24:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 04:24:01 -0000 Subject: [GHC] #10191: Interactive linker crash when partially applying seq# In-Reply-To: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> References: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> Message-ID: <059.6b3fb9b5704da5bffd4654c6c2e9256e@haskell.org> #10191: Interactive linker crash when partially applying seq# -------------------------------+----------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.4-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D759 -------------------------------+----------------------------------------- Changes (by rwbarton): * differential: => Phab:D759 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 05:00:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 05:00:54 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.bea3ca875dab23e09d8f8ecd56efee75@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I'm no expert on this part of the compiler, but it looks like GHC reduces the wanted constraint `Bar m m'` (from the use of `magic`) to `BarFamily m m' ~ 'True` (because of the `Bar` instance), and then it can no longer deduce that from `Bar m m'`. A peculiar scenario. It certainly looks wrong though, and FWIW GHC 7.6.3 accepts the program. The robust workaround is to add the superclass constraint `BarFamily m m' ~ 'True` to `Bar m m'`, since then (as you describe as "even more bizarrely") GHC can deduce either of `BarFamily m m' ~ 'True` and `Bar m m'` from the other, and then can't get stuck in this kind of situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 05:20:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 05:20:15 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.ce96caa2d8d18b364629c32daae8fbdc@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): Can you confirm in 7.10? Since we have no idea what's causing the issue, nor exactly what "this situation" is, it's possible this behavior could occur for a less generic instance in a situation where the instance constraint can't just be trivially promoted to a superclass constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 07:52:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 07:52:21 -0000 Subject: [GHC] #9723: Give Tab warning only once per file In-Reply-To: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> References: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> Message-ID: <061.1011f86616e828001d3c8d6b9a723547@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: dalaing Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 07:53:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 07:53:01 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.ddaae4a2a07bd34f07e05909117aa630@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T10177 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.10.1 => 7.10.2 Comment: GHC 7.10.1 was just released, so any change can occur in milestone:7.10.2 earliest (if it turns out there's nothing to change, please revert back to the 7.10.1 milestone) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 07:57:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 07:57:49 -0000 Subject: [GHC] #9780: dep_orphs in Dependencies redundantly records type family orphans In-Reply-To: <045.8bb223632e43c545d555772c72d364f6@haskell.org> References: <045.8bb223632e43c545d555772c72d364f6@haskell.org> Message-ID: <060.7789def7727c8eee04cfb99b0f0b2a19@haskell.org> #9780: dep_orphs in Dependencies redundantly records type family orphans -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.10.1 => 7.12.1 Comment: I guess this is 7.12 material now... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 09:05:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 09:05:23 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.f3ed8be5b8597eae64e15e25cfffdd8d@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 09:28:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 09:28:55 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers Message-ID: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #5108 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As reported by both hvr as user Yongqian Li: The Unicode7 update in GHC 7.10 had the side effect of breaking code making use of subscript symbols that did compile with GHC 7.8.4, but won't anymore with GHC 7.10.1: For instance, GHCi 7.8.4 accepts let x? = 1 let x? = 1 let x? = 1 let x? = 1 let x? = 1 let x? = 1 let x? = 1 whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC 7.8 does not accept *all* latin subscript letters either). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 09:30:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 09:30:57 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.ba95736aff10a8d3afbb5f085e6066aa@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #5108 | -------------------------------------+------------------------------------- Comment (by thomie): I think Simon's suggested change in [https://ghc.haskell.org/trac/ghc/ticket/5108#comment:4 #5108] would fix this: "allow the category Lm (MODIFIER LETTER) as part of an identifier? That would include all the primes and subscript/superscript things." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 09:34:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 09:34:38 -0000 Subject: [GHC] #10197: Release note links to Trac are wrong Message-ID: <046.db0c7be7cbdf5d0bc567f33daa660daa@haskell.org> #10197: Release note links to Trac are wrong -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-10-1.html the links to "issues" actually point to the Release Notes and not to Trac tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 09:36:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 09:36:11 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.e3e0a2d7aa4944f6845f4cafbd231c5a@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #5108 | -------------------------------------+------------------------------------- Old description: > As reported by both hvr as user Yongqian Li: > > The Unicode7 update in GHC 7.10 had the side effect of breaking code > making use of subscript symbols that did compile with GHC 7.8.4, but > won't anymore with GHC 7.10.1: > > For instance, GHCi 7.8.4 accepts > > let x? = 1 > let x? = 1 > let x? = 1 > let x? = 1 > let x? = 1 > let x? = 1 > let x? = 1 > > whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC > 7.8 does not accept *all* latin subscript letters either). New description: As reported by both hvr as user Yongqian Li: The [changeset:d4fd16801bc59034abdc6214e60fcce2b21af9c8 Unicode 7.0 update] in GHC 7.10 had the side effect of breaking code making use of subscript symbols that did compile with GHC 7.8.4, but won't anymore with GHC 7.10.1: For instance, GHCi 7.8.4 accepts {{{#!hs let x? = 1 let x? = 1 let x? = 1 let x? = 1 let x? = 1 let x? = 1 let x? = 1 }}} whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC 7.8 does not accept ''all'' latin subscript letters either). -- Comment (by hvr): Minor markup improvement in ticket-description -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 09:42:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 09:42:36 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.a1cf7ff5b79bac7f112688ad58bea58e@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #5108 | -------------------------------------+------------------------------------- Comment (by thomie): But perhaps don't allow a "MODIFIER LETTER" as the first character of an identifier. We're unfortunately outside of the report territory here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 09:51:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 09:51:53 -0000 Subject: [GHC] #5108: Allow unicode sub/superscript symbols in both identifiers and operators In-Reply-To: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> References: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> Message-ID: <072.3676394f26855c64e07a6548f30fd6d1@haskell.org> #5108: Allow unicode sub/superscript symbols in both identifiers and operators -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Status: infoneeded Type: feature request | Milestone: 7.12.1 Priority: normal | Version: 7.1 Component: Compiler | Keywords: lexer (Parser) | unicode Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10196 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10196 Comment: Replying to [comment:16 thomie]: > {{{ > ?> let ?x?y = 1 > }}} > > GHC 7.10 follows Unicode standard 7.0, in which `'?'` (`'\x2b9'`) is in the `ModifierLetter` (Lm) general category, so that will no longer compile. Ticket #10196 intends to fix this regression, by allowing MODIFIERLETTER in identifiers after the first character. Comments welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 10:08:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 10:08:44 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5OTQ3OiBVbmljb2RlIMKrb3RoZXIgbnVtYmVy?= =?utf-8?q?=C2=BB_characters_not_consistently_accepted_in_identif?= =?utf-8?q?iers?= In-Reply-To: <045.361e5fa432ad2a6e4cd46ab590186633@haskell.org> References: <045.361e5fa432ad2a6e4cd46ab590186633@haskell.org> Message-ID: <060.6013883ba3745e4f0b882166af39d2b4@haskell.org> #9947: Unicode ?other number? characters not consistently accepted in identifiers -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: worksforme | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4373 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: zardoz: please reopen if you do think there is a bug in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 10:09:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 10:09:26 -0000 Subject: [GHC] #10198: Build failure on Solaris/SPARC due to misaligned data access (bus error) Message-ID: <046.0901647091d6df0acafe17c72cab33d8@haskell.org> #10198: Build failure on Solaris/SPARC due to misaligned data access (bus error) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Building GHC Test Case: | failed Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Building of GHC 7.10.1 fails on Solaris/SPARC platform with: {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.12.1.1 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP- DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package-key Cabal_HWT8QvVfJLn2ubvobpycJY -package-key array_FaHmcBFfuRM8kmZLEY8D5S -package-key base_I5BErHzyOm07EBNpKBEeUv -package-key bytes_6vj5EoliHgNHISHCVCb069 -package-key conta_47ajk3tbda43DFWyeF3oHQ -package-key deeps_FpR4obOZALU1lutWnrBldi -package-key direc_3TcTyYedch32o1zTH2MR00 -package-key filep_5HhyRonfEZoDO205Wm9E4h -package-key ghc_IS8uiRKDTo1CRjcMAZsBb8 -package-key trans_ALYlebOVzVI4kxbFX5SGhm -package-key xhtml_0mVDYvYGgNUBWShvlDofr1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user- package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock- library/vendor/attoparsec-0.12.1.1/Data/Attoparsec/Number.hs -o utils/haddock/dist/build/Data/Attoparsec/Number.dyn_o gmake[1]: *** [utils/haddock/dist/build/Data/Attoparsec/Number.dyn_o] Bus Error (core dumped) gmake: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 10:15:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 10:15:45 -0000 Subject: [GHC] #10198: Build failure on Solaris/SPARC due to misaligned data access (bus error) In-Reply-To: <046.0901647091d6df0acafe17c72cab33d8@haskell.org> References: <046.0901647091d6df0acafe17c72cab33d8@haskell.org> Message-ID: <061.697581ed625a7fe68e63ff4b620b6b08@haskell.org> #10198: Build failure on Solaris/SPARC due to misaligned data access (bus error) ----------------------------------------+--------------------------------- Reporter: kgardas | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Changes (by kgardas): * status: new => merge Comment: The fix is already in HEAD. It was provided by Phab:D749 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 10:18:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 10:18:38 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.c6962a01c185e01c5e78179e48844cd9@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #5108 | -------------------------------------+------------------------------------- Comment (by yongqli): @Thomas Miedema, Yes, subscript characters only starting from the second character on is fine for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 11:47:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 11:47:52 -0000 Subject: [GHC] #9958: System.IO.Error: Fix a documentation link to Control.Exception.Exception In-Reply-To: <044.f8406cf4d09c8eb4152860b58e11bb5f@haskell.org> References: <044.f8406cf4d09c8eb4152860b58e11bb5f@haskell.org> Message-ID: <059.04cc4333b262e0e386de91d508b07a37@haskell.org> #9958: System.IO.Error: Fix a documentation link to Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => Comment: Link is still broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 11:48:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 11:48:30 -0000 Subject: [GHC] #8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception In-Reply-To: <048.8482d21568301182b05f72934f6258eb@haskell.org> References: <048.8482d21568301182b05f72934f6258eb@haskell.org> Message-ID: <063.fbfa6973c9faed1c16ddccb0d6f72125@haskell.org> #8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: shadewind | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #9958 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9958 Comment: This is being worked on in #9958. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 12:00:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 12:00:36 -0000 Subject: [GHC] #9723: Give Tab warning only once per file In-Reply-To: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> References: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> Message-ID: <061.54c6e4c6b70d656e7339b25cc6c43d3f@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: dalaing Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D760 -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch * differential: => Phab:D760 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 12:31:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 12:31:30 -0000 Subject: [GHC] #10193: TypeRep Show instance doesn't add parens around type operators In-Reply-To: <050.ff6cff2e03c64787c90e72c6c5c4a299@haskell.org> References: <050.ff6cff2e03c64787c90e72c6c5c4a299@haskell.org> Message-ID: <065.8ce7bdd26a5a07b6a790ea91b6f18bc2@haskell.org> #10193: TypeRep Show instance doesn't add parens around type operators -------------------------------------+------------------------------------- Reporter: pawel.nowak | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pawel.nowak): Replying to [comment:1 thomie]: > Fwiw, GHCi does the right thing already: Yes, but I think it works on GHC's internal Type, not on Typeable's TypeRep. \\ After some more thought, it would be useful to have an instance that prints a valid Haskell type, that is: * Parens around operators, * Fully qualified types, * No kinds - right now a TypeRep of e.g. "V 5" from Linear.V is printed as "V Nat 5". I'll implement that in Hint for now, but it would be nice to have that in Data.Typeable, possibly as an alternative to the current show instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 13:10:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 13:10:56 -0000 Subject: [GHC] #9723: Give Tab warning only once per file In-Reply-To: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> References: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> Message-ID: <061.83d3ac688bc14c013ef3327fcfc8d6f2@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: dalaing Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D760 -------------------------------------+------------------------------------- Comment (by hvr): I'm a bit dubious about this change. While I understand the intent it seems to the first warning which is not emitted at all occurrences. So tooling can't highlight all offending lines at once, and would need to be made aware that this warning actually affects more lines. So maybe the compromise would be to have a flag to enable warning *all* tab-polluted lines, but have it default to warn only about the first occurence -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 13:52:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 13:52:07 -0000 Subject: [GHC] #9723: Give Tab warning only once per file In-Reply-To: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> References: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> Message-ID: <061.87bb15305b1b42442ff74d464f4d7fee@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: dalaing Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D760 -------------------------------------+------------------------------------- Comment (by goldfire): While I generally agree with @hvr in wanting to think about tooling, I disagree in this instance. It's ''very'' easy for tooling to find tabs on its own -- much easier, I would bargain, than trying to parse GHC's warnings. And maintaining two different warnings, with their own flags, for "warn once" vs. "warn every time" seems heavy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 14:49:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 14:49:06 -0000 Subject: [GHC] #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 In-Reply-To: <046.cfdb0dc1b2281b62f1e87667e0f4270a@haskell.org> References: <046.cfdb0dc1b2281b62f1e87667e0f4270a@haskell.org> Message-ID: <061.e1e009b077118ff14f77c186e590b674@haskell.org> #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 -------------------------------------+------------------------------------- Reporter: stengel | Owner: Type: bug | thoughtpolice Priority: high | Status: patch Component: Runtime System | Milestone: 7.12.1 Resolution: | Version: 7.8.1 Operating System: Unknown/Multiple | Keywords: Type of failure: Other | Architecture: x86_64 Blocked By: | (amd64) Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * owner: simonmar => thoughtpolice Comment: Looks good to me - @thoughtpolice could you put it in your next validate run? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 15:01:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 15:01:37 -0000 Subject: [GHC] #9723: Give Tab warning only once per file In-Reply-To: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> References: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> Message-ID: <061.e44ffb4cd805fc2fc5a340cc41b52c6d@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: dalaing Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D760 -------------------------------------+------------------------------------- Comment (by nomeata): > So tooling can't highlight all offending lines at once, and would need to be made aware that this warning actually affects more lines. This is a good thing. If you edit a file with tabs in every line, highlighting every line is more annoying than helpful, IMHO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 15:08:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 15:08:11 -0000 Subject: [GHC] #10199: Sending SIGINT to a program that uses forkOS may crash with various errors Message-ID: <044.16ed099f787ddebd86daad09ea2544a1@haskell.org> #10199: Sending SIGINT to a program that uses forkOS may crash with various errors -------------------------------------+------------------------------------- Reporter: adeon | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Linux Keywords: | Type of failure: Runtime crash Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is the program: {{{#!hs module Main ( main ) where import Control.Concurrent import Control.Monad main :: IO () main = recursive 0 where recursive n = do tid <- forkIO $ do replicateM_ 100 $ forkOS $ return () replicateM_ (n `mod` 1000) yield recursive (n+1) }}} I was trying to investigate a potential issue with leaking StablePtrs in forkOS but that's another story. Compile with {{{ghc Main.hs -prof -auto-all -threaded -o Main}}}. Run as {{{./Main +RTS -h}}} (I don't know if it's absolutely necessary to turn heap profiling on but I have more trouble getting these error messages without it). Then, stop the program with SIGINT (by pressing CTRL+C or otherwise). The program sometimes crashes and produces one of the these two error messages: {{{ Main: internal error: RELEASE_LOCK: I do not own this lock: rts/Task.c 242 (GHC version 7.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ Main: newBoundTask: RTS is not initialised; call hs_init() first }}} Sometimes the message may be slightly garbled (notice double internal error below): {{{ ?: internal error: Main: internal error: RELEASE_LOCK: I do not own this lock: rts/Task.c 242 (GHC version 7.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Replacing forkOS with forkIO seems to stop the messages. I can't reproduce this on FreeBSD. I'm using the downloaded binaries of 7.10.1 from GHC site on Arch Linux. I used this simple bash script to see more of these messages because it won't crash reliably: {{{#!bash #!/bin/bash while true; do timeout -s INT 0.2 ./Main +RTS -h done }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 15:39:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 15:39:53 -0000 Subject: [GHC] #10191: Interactive linker crash when partially applying seq# In-Reply-To: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> References: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> Message-ID: <059.1a0bacb66d01ce56720a9923f1daad9e@haskell.org> #10191: Interactive linker crash when partially applying seq# -------------------------------+----------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.4-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D759 -------------------------------+----------------------------------------- Comment (by Reid Barton ): In [changeset:"af45feba476af0b5a12f3a1ac36854f2cf44f993/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="af45feba476af0b5a12f3a1ac36854f2cf44f993" Update list of primops that don't get wrappers (#10191) Summary: The list was 14 years old, and there don't seem to be any problems with seq# or par#; the other par*# primops were not actually implemented at all and were removed in D758. Test Plan: validate; will also try to locally validate an unregisterised build in case there was some truth to the deleted comment Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D759 GHC Trac Issues: #10191 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 15:49:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 15:49:15 -0000 Subject: [GHC] #10191: Interactive linker crash when partially applying seq# In-Reply-To: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> References: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> Message-ID: <059.a947f039cf28a61339192880fbf13784@haskell.org> #10191: Interactive linker crash when partially applying seq# -------------------------------+----------------------------------------- Reporter: mniip | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: GHCi | Version: 7.8.4-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D759 -------------------------------+----------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 17:29:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 17:29:58 -0000 Subject: [GHC] #10200: Documentation not built for base Message-ID: <048.7df6e1463b7cc8cc2db0bff6569669ba@haskell.org> #10200: Documentation not built for base -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- None of the modules from the base package appear in the documentation that shipped with the binary distribution. I am looking at share/doc/ghc/html/libraries/index.html and no modules from base are in there. This is the binary distribution for 64-bit Linux that I downloaded from haskell.org, although I also had this same problem when I built rc3 from source using GHC 7.8 on Mac OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 18:19:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 18:19:37 -0000 Subject: [GHC] #10201: Weak inference when using rank-2 types and type families. Message-ID: <047.471298fbb2fe9a40aed790e445c73723@haskell.org> #10201: Weak inference when using rank-2 types and type families. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type inference does work as expected, when a rank-2 type has type-family constraint. Consider the following program: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} type family F a f :: (forall s. (F s ~ Int) => s -> b) -> b f _ = undefined k :: s -> Char k = undefined example :: Bool example = const True (f k) }}} It is rejected with the following error: {{{ Couldn't match type ?b0? with ?Char? ?b0? is untouchable inside the constraints (F s ~ Int) bound by a type expected by the context: (F s ~ Int) => s -> b0 at bug.hs:13:23-25 Expected type: s -> b0 Actual type: s -> Char In the first argument of ?f?, namely ?k? In the second argument of ?const?, namely ?(f k)? }}} This is unexpected because the result of `f` should be the same as the result of its parameter, and we know the exact type of the parameter, namely `Char`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 18:19:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 18:19:45 -0000 Subject: [GHC] #10202: Weak inference when using rank-2 types and type families. Message-ID: <047.b9bd5d82be8cb36fbd3020532b7256bf@haskell.org> #10202: Weak inference when using rank-2 types and type families. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type inference does work as expected, when a rank-2 type has type-family constraint. Consider the following program: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} type family F a f :: (forall s. (F s ~ Int) => s -> b) -> b f _ = undefined k :: s -> Char k = undefined example :: Bool example = const True (f k) }}} It is rejected with the following error: {{{ Couldn't match type ?b0? with ?Char? ?b0? is untouchable inside the constraints (F s ~ Int) bound by a type expected by the context: (F s ~ Int) => s -> b0 at bug.hs:13:23-25 Expected type: s -> b0 Actual type: s -> Char In the first argument of ?f?, namely ?k? In the second argument of ?const?, namely ?(f k)? }}} This is unexpected because the result of `f` should be the same as the result of its parameter, and we know the exact type of the parameter, namely `Char`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 18:20:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 18:20:30 -0000 Subject: [GHC] #10203: Weak inference when using rank-2 types and type families. Message-ID: <047.b2e09165e84d91e24c7b43fd58570a81@haskell.org> #10203: Weak inference when using rank-2 types and type families. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type inference does work as expected, when a rank-2 type has type-family constraint. Consider the following program: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} type family F a f :: (forall s. (F s ~ Int) => s -> b) -> b f _ = undefined k :: s -> Char k = undefined example :: Bool example = const True (f k) }}} It is rejected with the following error: {{{ Couldn't match type ?b0? with ?Char? ?b0? is untouchable inside the constraints (F s ~ Int) bound by a type expected by the context: (F s ~ Int) => s -> b0 at bug.hs:13:23-25 Expected type: s -> b0 Actual type: s -> Char In the first argument of ?f?, namely ?k? In the second argument of ?const?, namely ?(f k)? }}} This is unexpected because the result of `f` should be the same as the result of its parameter, and we know the exact type of the parameter, namely `Char`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 18:29:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 18:29:06 -0000 Subject: [GHC] #10204: Odd interaction between rank-2 types and type families Message-ID: <047.40c7f4223ed199be95aee7f3ef8794b7@haskell.org> #10204: Odd interaction between rank-2 types and type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type inference does work as expected, when a rank-2 type has type-family constraint. Consider the following program: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} type family F a f :: (forall s. (F s ~ Int) => s -> b) -> b f _ = undefined k :: s -> Char k = undefined example :: Bool example = const True (f k) }}} It is rejected with the following error: {{{ Couldn't match type ?b0? with ?Char? ?b0? is untouchable inside the constraints (F s ~ Int) bound by a type expected by the context: (F s ~ Int) => s -> b0 at bug.hs:13:23-25 Expected type: s -> b0 Actual type: s -> Char In the first argument of ?f?, namely ?k? In the second argument of ?const?, namely ?(f k)? }}} This is unexpected because the result of `f` should be the same as the result of its parameter, and we know the exact type of the parameter, namely `Char`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 18:31:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 18:31:09 -0000 Subject: [GHC] #10201: Weak inference when using rank-2 types and type families. In-Reply-To: <047.471298fbb2fe9a40aed790e445c73723@haskell.org> References: <047.471298fbb2fe9a40aed790e445c73723@haskell.org> Message-ID: <062.65aadd3d420954ada9f29f0a246a5a59@haskell.org> #10201: Weak inference when using rank-2 types and type families. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: duplicate | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10204 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #10204 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 18:32:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 18:32:31 -0000 Subject: [GHC] #10202: Weak inference when using rank-2 types and type families. In-Reply-To: <047.b9bd5d82be8cb36fbd3020532b7256bf@haskell.org> References: <047.b9bd5d82be8cb36fbd3020532b7256bf@haskell.org> Message-ID: <062.d8d3a5fff815ad9be2de07b899206c5d@haskell.org> #10202: Weak inference when using rank-2 types and type families. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: duplicate | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10204 | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #10204 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 18:33:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 18:33:27 -0000 Subject: [GHC] #10203: Weak inference when using rank-2 types and type families. In-Reply-To: <047.b2e09165e84d91e24c7b43fd58570a81@haskell.org> References: <047.b2e09165e84d91e24c7b43fd58570a81@haskell.org> Message-ID: <062.0dd60e52f9ec15f6b4526e6a347aa0a2@haskell.org> #10203: Weak inference when using rank-2 types and type families. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: duplicate | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10204 | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #10204 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 18:36:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 18:36:59 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.fa35fb1e6def992f8c143c39dd8ca9a0@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, the original program fails to compile in 7.8.1, 7.10-rc-something, and HEAD, though I didn't try your variations to see if they have the same behavior also. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 20:50:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 20:50:49 -0000 Subject: [GHC] #10204: Odd interaction between rank-2 types and type families In-Reply-To: <047.40c7f4223ed199be95aee7f3ef8794b7@haskell.org> References: <047.40c7f4223ed199be95aee7f3ef8794b7@haskell.org> Message-ID: <062.ca001ce007f820f745d397b39f22a34c@haskell.org> #10204: Odd interaction between rank-2 types and type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): Just to note: this is not a regression for 7.10. The identical behavior appears in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 21:05:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 21:05:38 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.19e066561e14d04ee275a5432a26d863@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Interesting. One problem with this code is that it sports some overlapping instances. Your local `Bar m m'` constraint overlaps with the global `Bar m m'` instance. It's not terribly surprising to me that GHC gets confused here. This is a dark corner of `FlexibleInstances`. Part of the problem is that it's hard for GHC to know what the type of `magic $ scinv * b` should be. Due to the GADT pattern-match, it doesn't want to guess that the type should be `Foo m zp (c m' zq)`, as that choice might be ignoring some information gained in the pattern-match. My guess is that some of your deltas cause GHC to deduce that no equalities are learned in the pattern-match, and thus that result type inference is safe. In any case, I don't think GHC is "forgetting" anything here. It's just choosing one seemingly-viable route toward a solution (the global instance) instead of another, the local constraint. I do agree that this behavior is somewhat disconcerting, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 21:29:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 21:29:59 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.8f1fcd3483c11322e027242918c2a319@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): goldfire: In what sense does the `Bar m m'` constraint overlap with the instance? As far as I was aware, it would be impossible to have "overlapping" instances with just a single instance. This is likely just a misunderstanding of the term on my part. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 22:24:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 22:24:23 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date Message-ID: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Incorrect result Test Case: | at runtime Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- When I ran {{{ghc-pkg list}}} on Windows, it reported that the global and user caches were out of date. As instructed, I recached both caches. Despite this, I continued to get the same error message. It appears that the timestamp on the package.conf.d directory is always a few milliseconds later than the timestamp of the package cache, even after recaching, as shown by the log excerpt below. Original error: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg check WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] }}} Checking timestamps: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list Timestamp 2015-03-27 21:18:29.5247984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa ckage.cache Timestamp 2015-03-27 21:18:29.5277984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N EWER than cache) WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] Timestamp 2015-03-27 21:15:48.6285984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache Timestamp 2015-03-27 21:15:48.6835984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c ache) WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] }}} Recaching as instructed: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --user [snip...] modifying: Just "C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d" flag db stack: ["C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d"] writing cache C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --global [snip...] modifying: Just "C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d" flag db stack: ["C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d"] writing cache C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache }}} Looking at timestamps after recaching: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list Timestamp 2015-03-27 21:21:50.3341984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa ckage.cache Timestamp 2015-03-27 21:21:50.3371984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N EWER than cache) WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] Timestamp 2015-03-27 21:23:05.4329984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache Timestamp 2015-03-27 21:23:05.4359984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c ache) WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. C:\Users\hgolden\AppData\Roaming> }}} Timestamps have changed, but each directory's timestamp is still a few milliseconds after each cache file's timestamp. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 27 23:08:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Mar 2015 23:08:46 -0000 Subject: [GHC] #9723: Give Tab warning only once per file In-Reply-To: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> References: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> Message-ID: <061.090d5c2c169fb22203d173a1d44c87a5@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: dalaing Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D760 -------------------------------------+------------------------------------- Comment (by dalaing): I was a bit torn as well. I mostly liked the idea of picking some low hanging fruit to get into GHC hacking :) I like using the go-to-previous-error and go-to-next-error features in my editor, and if a few tabs have crept in it'd be nice to just fix them up in my usual cycle. On the other hand, most of the tabs I've come across in the checkout of GHC have been in files where tabs are used consistently throughout the file (time, xhtml, ...) - in which case I'd prefer one warning after which I'd get my editor to retab the file and move on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 05:55:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 05:55:11 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.6f4d9666c0cdbf499394f5a3c1de421d@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by javran): I'm newcomer and thinking about working on this ticket. I investigated a little bit, there are currently 3 places where a RTS suggestion appears: * in `StackOverflowHook` of `rts/hooks/StackOverflow.c`: {{{ fprintf(stderr, "Stack space overflow: current size %" FMT_Word " bytes.\nUse `+RTS -Ksize -RTS' to increase it.\n", stack_size); }}} * in `OutOfHeapHook` of `rts/hooks/OutOfHeap.c` {{{ if (heap_size > 0) { errorBelch("Heap exhausted;\nCurrent maximum heap size is %" FMT_Word " bytes (%" FMT_Word " MB);\nuse `+RTS -M' to increase it.", heap_size, heap_size / (1024*1024)); } else { errorBelch("out of memory"); } }}} * in `nextEra` of `rts/ProfHeap.c`: {{{ if (era == max_era) { errorBelch("maximum number of censuses reached; use +RTS -i to reduce"); stg_exit(EXIT_FAILURE); } }}} And the error message saying `"Most RTS options are disabled."` comes from `rts/RtsFlags.c`. It seems that we need to know the value of `RtsOptsEnabledEnum enabled` to tell whether RTS options are available, but this value is only passed around `setupRtsFlags` and `procRtsOpts` during command line parsing. Is there some way to check the availability of RTS options for 3 places I mentioned above? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 07:05:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 07:05:28 -0000 Subject: [GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" Message-ID: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: | Version: 7.10.1-rc1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This was originally spotted and [https://mail.haskell.org/pipermail/ghc- devs/2015-February/008407.html posted to the ghc-devs mailing list] by Joachmin Breitner, but apparently since nobody has submitted a ticket for this relatively serious issue, here it is. I am quoting Joachim: {{{ while the index at http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/index.html exists, navigating to http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/Data- Char.html yields a 404 error. Same for http://haskell.inf.elte.hu/docs/latest/html/libraries/Data-Char.html }}} And [https://mail.haskell.org/pipermail/ghc-devs/2015-February/008408.html I have replied] the following to his initial email (I am involved in this because I am doing daily snapshots of the documentation through my FreeBSD GHC builders): {{{ Yes, I can confirm this bug. For what it is worth, the files are all there, the link appears to be broken: it is missing the subdirectory with the name of the package. That is, the proper link should be something like that: http://haskell.inf.elte.hu/docs/7.9.20141222.noWin32/html/libraries/base-4.8.0.0 /Data-Char.html (Note the missing "base-4.8.0.0".) I have checked this with GHC 7.8.3, and everything is right there, while this problem seems to appear with GHC 7.10 RC2 and GHC-HEAD (starting from somewhere between mid-September and November -- that is what a quick bisecting tells me). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 07:06:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 07:06:13 -0000 Subject: [GHC] #10200: Documentation not built for base In-Reply-To: <048.7df6e1463b7cc8cc2db0bff6569669ba@haskell.org> References: <048.7df6e1463b7cc8cc2db0bff6569669ba@haskell.org> Message-ID: <063.c268f8d867750310c2ef9c9ed58c9dac@haskell.org> #10200: Documentation not built for base -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pgj): I think this might be related to #10206? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 09:20:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 09:20:33 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.796e2cf4b84d63d0a6fa526c604ce8d6@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Couldn't you store `RtsOptsEnabledEnum` in the `RtsFlags` struct? See `includes/rts/Flags.h`, initialization in `rts/RtsFlags.c`. Then use it those 3 places. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 12:57:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 12:57:40 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.1de7bd40e0d90b2fd1e054849d75297c@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): I'm unhappy with this change, because it uses a language extension that affects accepted **input** (namely, `UnicodeSyntax`) to modify the **output** of ghci. I would prefer having a ghci-specific option (say, `:set +/-u` or more verbosely, `:set +/-unicodeoutput`) instead. This is not just cosmetics; the current behaviour broke lambdabot's `:t` and `:k` commands, which parse ghci's output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 13:03:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 13:03:40 -0000 Subject: [GHC] #10207: parser: ParStmt has incorrect SrcSpan Message-ID: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> #10207: parser: ParStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The production for pquals is {{{#!hs pquals :: { Located [[LStmt RdrName (LHsExpr RdrName)]] } : squals '|' pquals {% addAnnotation (gl $ last $ unLoc $1) AnnVbar (gl $2) >> return (L (getLoc $2) (reverse (unLoc $1) : unLoc $3)) } | squals { L (getLoc $1) [reverse (unLoc $1)] } }}} This assigns the location of the '|' to the entire returned value. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 14:12:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 14:12:54 -0000 Subject: [GHC] #10207: parser: ParStmt has incorrect SrcSpan In-Reply-To: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> References: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> Message-ID: <059.5a2b7ed3c9d539d09e35c7ad2895117f@haskell.org> #10207: parser: ParStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 18:29:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 18:29:04 -0000 Subject: [GHC] #10208: libffi issues executable stacks on i386 Message-ID: <045.d069052078e86f4dc9cd61c2cbb3a538@haskell.org> #10208: libffi issues executable stacks on i386 -----------------------------------------+--------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: D764 | -----------------------------------------+--------------------------------- Noticed today when built binaries for i386-gentoo-linux. Latest build phase checks for executable stacks in final result. {{{ * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so.6.0.2 * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so.6 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_p.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_l.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_debug.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_debug.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_l.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_p.a:win32.o }}} Issue first found and fixed in gentoo: http://bugs.gentoo.org/511634 and then sent upstream: http://sourceware.org/ml/libffi-discuss/2014/msg00058.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 18:43:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 18:43:40 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.85bdef9b7fc4f504b0b461cdad0edd47@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by shachaf): I have the same problem with this change as int-e -- the extension previously affected only input and now silently started to affect output too. I've turned it off in my `.ghci` as a result. I also think that a separate output flag is the right approach -- compare `-XExplicitForAll` vs. `-fprint-explicit-foralls`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 18:49:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 18:49:01 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan Message-ID: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The production for opt_kind_sig is {{{#!hs opt_kind_sig :: { Located (Maybe (LHsKind RdrName)) } : { noLoc Nothing } | '::' kind {% ajl (sLL $1 $> (Just $2)) AnnDcolon (gl $1) } }}} The outer Location is used only to get the full span for the enclosing declration, and is then stripped. The inner LHsKind then has a SrcSpan that does not include the '::' Extend the SrcSpan on $2 to include $1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 21:00:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 21:00:57 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.1359b20dfaf770f0ddd6e94c2c726e7b@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): The reference to `-XExplicitForAll` vs. `-fprint-explicit-foralls` is a good point.. But it?s already released, so any tools that are broken will likely get a fix anyways. I?m unsure on how to proceed here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 22:15:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 22:15:43 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.b5cc7664a4c22cf1966026d1f4d18d27@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): I'm sorry I didn't find this while testing the release candidates. I did not expect such "simple" ghci queries to break, and besides lambdabot does not enable `UnicodeSyntax` by default, that's a customization for the one running on Freenode. My current "fix" for lambdabot to disable `UnicodeSyntax` for the two affected commands. This is the only sensible option because I do not want lambdabot to use the unicode symbols in its type signatures; in other words, fixing lambdabot properly (such that unicode syntax is allowed in the input) is not possible at this time. How would you feel about keeping the current behaviour by default, but adding flags `-fprint-unicode-syntax` and `-fno-print-unicode-syntax` to override the default, regardless of whether `UnicodeSyntax` is enabled or not? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 23:40:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 23:40:51 -0000 Subject: [GHC] #10210: Documentation link to 7.10.1 migration guide broken Message-ID: <052.f02bf8afd4996dd8619e6f1820ea86bb@haskell.org> #10210: Documentation link to 7.10.1 migration guide broken -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple Documentation | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When publishing the users guide to https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-10-1.html, several users reported the 'Migration Guide' hyperlinks were broken. Turns out they were; the HTML looked something like this: {{{

  • GHC has implemented "The Applicative Monad Proposal", meaning the Applicative typeclass is now a superclass of Monad. This is a breaking change and your programs will need to be updated. Please see the GHC 7.10 Migration Guide on the GHC wiki. }}} with an empty `href`. This ticket is so we don't lose track of this bug for 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 23:41:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 23:41:12 -0000 Subject: [GHC] #10210: Documentation link to 7.10.1 migration guide broken In-Reply-To: <052.f02bf8afd4996dd8619e6f1820ea86bb@haskell.org> References: <052.f02bf8afd4996dd8619e6f1820ea86bb@haskell.org> Message-ID: <067.dabb62f51872c195429611d1075fcfd5@haskell.org> #10210: Documentation link to 7.10.1 migration guide broken -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): (Note that I fixed the online copy by hand editing it.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 23:43:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 23:43:14 -0000 Subject: [GHC] #10198: Build failure on Solaris/SPARC due to misaligned data access (bus error) In-Reply-To: <046.0901647091d6df0acafe17c72cab33d8@haskell.org> References: <046.0901647091d6df0acafe17c72cab33d8@haskell.org> Message-ID: <061.6878ab3e51ddf6ccc78f8b17ec722308@haskell.org> #10198: Build failure on Solaris/SPARC due to misaligned data access (bus error) ----------------------------------------+--------------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.2 Comment: Merged via 0b655e5d89f6ebd1e3fb6b640d7f628b723c3c08. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 23:44:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 23:44:24 -0000 Subject: [GHC] #10208: libffi issues executable stacks on i386 In-Reply-To: <045.d069052078e86f4dc9cd61c2cbb3a538@haskell.org> References: <045.d069052078e86f4dc9cd61c2cbb3a538@haskell.org> Message-ID: <060.da8b4f2e947932dd46e8a13f8f1a67e7@haskell.org> #10208: libffi issues executable stacks on i386 -----------------------------------+------------------------------------ Reporter: slyfox | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D764 -----------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => patch * differential: D764 => Phab:D764 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 28 23:47:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 23:47:05 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.4f2674861edb62106e59635767dfe46f@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | indexed_types/should_fail/T9160 Related Tickets: #4524 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): I am also see this on ghc 7.10.1, not sure if this is another instance of this bug: cabal install bitmap [ 3 of 10] Compiling Data.Bitmap.IO ( Data/Bitmap/IO.hs, dist/build/Data/Bitmap/IO.o ) Data/Bitmap/IO.hs:1248:1: Warning: SPECIALISE pragma for non-overloaded function ?myPlusPtr? Data/Bitmap/IO.hs:1249:1: Warning: SPECIALISE pragma for non-overloaded function ?myPlusPtr? ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Template variable unbound in rewrite rule $fPixelComponentFloat3_X2Rc [$fPixelComponentFloat3_X2Rc] [$fPixelComponentFloat3_X2Rc] [] [] 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 Mar 28 23:48:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Mar 2015 23:48:00 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.442db495eabdd075c5f780fc20918c38@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | indexed_types/should_fail/T9160 Related Tickets: #4524 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by George): * cc: george (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 04:15:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 04:15:27 -0000 Subject: [GHC] #10211: Validate fails in RTS tests on Mac OS X Message-ID: <046.ceeba31edc5276171ff0db279007810e@haskell.org> #10211: Validate fails in RTS tests on Mac OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9389 rts/linker_unload | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The failure of rts/linker_unload is due to an #include which isn't found on OS X. It appears to be needed for Windows. I think we can either use CPP to remove the include for Mac OS X or to conditionally do # include instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 04:20:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 04:20:24 -0000 Subject: [GHC] #10211: Validate fails in RTS tests on Mac OS X In-Reply-To: <046.ceeba31edc5276171ff0db279007810e@haskell.org> References: <046.ceeba31edc5276171ff0db279007810e@haskell.org> Message-ID: <061.10a6b47c3d58401f6d98a969d8ecf2a0@haskell.org> #10211: Validate fails in RTS tests on Mac OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9389 | rts/linker_unload | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 06:42:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 06:42:40 -0000 Subject: [GHC] #10211: Validate fails in RTS tests on Mac OS X In-Reply-To: <046.ceeba31edc5276171ff0db279007810e@haskell.org> References: <046.ceeba31edc5276171ff0db279007810e@haskell.org> Message-ID: <061.44d9821bea1b62e1bf0ac479c729039f@haskell.org> #10211: Validate fails in RTS tests on Mac OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9389 | rts/linker_unload | Blocking: | Differential Revisions: Phab:D765 -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch * differential: => Phab:D765 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 07:54:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 07:54:00 -0000 Subject: [GHC] #10212: The testsuite cleans up hpc files, even if they are part of a test. Message-ID: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> #10212: The testsuite cleans up hpc files, even if they are part of a test. -------------------------------------+------------------------------------- Reporter: dalaing | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: hpc/T10138 | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Multiple validate runs start to fail hpc/T10138, since the .tix file and .hpc directory get cleaned up. It seems there are two options here - we could make the test generate the .tix file and .hpc directory as it runs, or we could add an option to the test driver to not clean those files up for certain tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 07:54:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 07:54:13 -0000 Subject: [GHC] #10212: The testsuite cleans up hpc files, even if they are part of a test. In-Reply-To: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> References: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> Message-ID: <061.8f0f113e2a9b2d2d5d3179b672599894@haskell.org> #10212: The testsuite cleans up hpc files, even if they are part of a test. -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: hpc/T10138 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 07:58:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 07:58:49 -0000 Subject: [GHC] #10212: The testsuite cleans up hpc files, even if they are part of a test. In-Reply-To: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> References: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> Message-ID: <061.a6b984dcd259c4255e8bdda2ea780c98@haskell.org> #10212: The testsuite cleans up hpc files, even if they are part of a test. -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: hpc/T10138 Related Tickets: | Blocking: | Differential Revisions: Phab:D766 -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch * differential: => Phab:D766 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 08:17:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 08:17:42 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.846e98d56ffd3277de491d5065d29921@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by javran): * owner: => javran -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 11:25:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 11:25:22 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.f4e7887cbd9e29315194de23f265468f@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D767 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 12:32:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 12:32:57 -0000 Subject: [GHC] #10200: Documentation not built for base In-Reply-To: <048.7df6e1463b7cc8cc2db0bff6569669ba@haskell.org> References: <048.7df6e1463b7cc8cc2db0bff6569669ba@haskell.org> Message-ID: <063.daf07eb84d2b20ddcc36b5accb0eecdd@haskell.org> #10200: Documentation not built for base -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by massysett): Yes, I hadn't realized that the docs are there, they're just not linked from the main index. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 12:41:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 12:41:35 -0000 Subject: [GHC] #10200: Documentation not built for base In-Reply-To: <048.7df6e1463b7cc8cc2db0bff6569669ba@haskell.org> References: <048.7df6e1463b7cc8cc2db0bff6569669ba@haskell.org> Message-ID: <063.cb90cf615a57559afd5e0659b2cc2306@haskell.org> #10200: Documentation not built for base -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #10206 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10206 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 13:40:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 13:40:58 -0000 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> References: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> Message-ID: <064.c602cbcdf9973691ad9de77dd8035fff@haskell.org> #2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by waern): * cc: hvr (added) * failure: => None/Unknown Comment: Like Igloo said, I think we should just add Haddock comments to the .hi files. We are already storing meta data in there such as annotations. Incidentally, if we do this then Haddock might also eventually be able to generate docs purely based on .hi files (useful in some cases). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 14:37:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 14:37:23 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.85461b91fc423290134e5a39e6f09b59@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): It may be necessary to change {{{#!hs type HsKind name = HsType name }}} {{{#!hs type HsKind name = LHsType name }}} So that the '::' can be annotated separately from the kind. Otherwise we have a problem for {{{#!hs HsTyVar name }}} where we have been using the surrounding span for the annotation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 14:47:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 14:47:10 -0000 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> References: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> Message-ID: <064.0524485f7db53084b4f21c221c25d002@haskell.org> #2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: Fuuzetsu (added) * priority: lowest => normal Comment: Adding Mateusz who may be able to contribute some comments, as I've been bugging him for some time already about adding the raw Haddock markup to `.hi` files... :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 15:36:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 15:36:59 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.444efd656f756dd336e8f62ca06c6b2e@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10189 | -------------------------------------+------------------------------------- Changes (by Kinokkory): * cc: Kinokkory (added) * owner: => Kinokkory * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 16:33:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 16:33:55 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.3526ce8dc3c508105acd13eddebb2df8@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Phab:D768 Related Tickets: #10189 | -------------------------------------+------------------------------------- Changes (by Kinokkory): * status: new => patch * differential: => Phab:D768 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 16:58:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 16:58:42 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.31b85621faf639661b2a78299adf92fb@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Phab:D768 Related Tickets: #10189 | -------------------------------------+------------------------------------- Comment (by Kinokkory): This patch makes `(:) Int [Float, Double]` and `Int : [Float, Double]` parsed. In fact, infix type-level cons also used to be not parsed without `'`. Essentially, I changed the definition of `tyconsym` by adding `| ':' ...`. {{{ tyconsym :: { Located RdrName } : CONSYM { sL1 $1 $! mkUnqual tcClsName (getCONSYM $1) } | VARSYM { sL1 $1 $! mkUnqual tcClsName (getVARSYM $1) } | ':' { sL1 $1 $! consDataCon_RDR } | '*' { sL1 $1 $! mkUnqual tcClsName (fsLit "*") } | '-' { sL1 $1 $! mkUnqual tcClsName (fsLit "-") } }}} By the way I wonder what `| '*' ...` and `| '-' ...` are for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 17:52:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 17:52:07 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.5b8e108c4d745d0a5f1bcee7cdd1eadf@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | indexed_types/should_fail/T9160 Related Tickets: #4524 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:13 George]: > I am also seeing this on ghc 7.10.1, not sure if this is another instance of this bug: > > cabal install bitmap > [ 3 of 10] Compiling Data.Bitmap.IO ( Data/Bitmap/IO.hs, dist/build/Data/Bitmap/IO.o ) I've distilled it a bit to a selfcontained test: {{{#!hs -- sf 9160 # cat B.hs {-# LANGUAGE NoImplicitPrelude #-} {-# OPTIONS_GHC -O2 #-} module B (bug) where data D = D data E = E class Storable a where poke2 :: a -> E instance Storable D where poke2 = poke2 -- undefined class Foo a where instance Foo D where class (Foo t, Storable t) => FooStorable t where instance FooStorable D where {-# SPECIALIZE instance FooStorable D #-} {-# SPECIALIZE bug :: D -> E #-} bug :: FooStorable t => t -> E bug = poke2 {- sf 9160 # ghc -c -fforce-recomp -Wall B.hs B.hs:5:10: Warning: Defined but not used: data constructor ?D? B.hs:6:10: Warning: Defined but not used: data constructor ?E? ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Template variable unbound in rewrite rule $fFooStorableD_XU [$fFooStorableD_XU] [$fFooStorableD_XU] [] [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 18:05:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 18:05:05 -0000 Subject: [GHC] #10212: The testsuite cleans up hpc files, even if they are part of a test. In-Reply-To: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> References: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> Message-ID: <061.c30fafcaa0096f39fd6f99b5972fc877@haskell.org> #10212: The testsuite cleans up hpc files, even if they are part of a test. -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: hpc/T10138 Related Tickets: | Blocking: | Differential Revisions: Phab:D766 -------------------------------------+------------------------------------- Changes (by javran): * cc: javran (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 21:31:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 21:31:46 -0000 Subject: [GHC] #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect Message-ID: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect -------------------------------------+------------------------------------- Reporter: bmjames | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The [https://downloads.haskell.org/~ghc/7.10.1/docs/users_guide.pdf GHC user guide], section 1.5.2.2: -fwarn-tabs warning flag is turned on by default with this release of GHC. However, section 4.8, regarding -fwarn-tabs, still says: This warning is off by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 22:26:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 22:26:48 -0000 Subject: [GHC] #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect In-Reply-To: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> References: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> Message-ID: <061.e3204829168e18a71bc3195f543e89a4@haskell.org> #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect -------------------------------------+------------------------------------- Reporter: bmjames | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 22:36:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 22:36:17 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=239933=3A_Cross-compile_failure_=3A_N?= =?utf-8?b?b3QgaW4gc2NvcGU6IOKAmGdjZEludCfigJk=?= In-Reply-To: <044.5fbd4764d2309354b240e8b3ffabc8d1@haskell.org> References: <044.5fbd4764d2309354b240e8b3ffabc8d1@haskell.org> Message-ID: <059.3beabd38df794f5bd035e10f7646aaef@haskell.org> #9933: Cross-compile failure : Not in scope: ?gcdInt'? -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D598 -------------------------------------+------------------------------------- Changes (by erikd): * status: patch => closed * resolution: => fixed Comment: This seems to have been fixed in another commit. I have been building a GHC linux-amd64 to linux-armhf cross compiler using `BuildFlavour=quick- cross` (which using integer-simple) in a Jenkins instance for weeks without problems. Closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 22:57:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 22:57:28 -0000 Subject: [GHC] #10214: parser: TransStmt has incorrect SrcSpan Message-ID: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> #10214: parser: TransStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The production for `squals` is. {{{#!hs squals :: { Located [LStmt RdrName (LHsExpr RdrName)] } -- In reverse order, because the last -- one can "grab" the earlier ones : squals ',' transformqual {% addAnnotation (gl $ last $ unLoc $1) AnnComma (gl $2) >> return (sLL $1 $> [L (getLoc $3) ((unLoc $3) (reverse (unLoc $1)))]) } }}} The location of the whole statement is set to that `transformqual` when it fact it should encompass the whole production. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 22:58:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 22:58:41 -0000 Subject: [GHC] #10212: The testsuite cleans up hpc files, even if they are part of a test. In-Reply-To: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> References: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> Message-ID: <061.d6c2e7bf29bbc93d070805b4572300a0@haskell.org> #10212: The testsuite cleans up hpc files, even if they are part of a test. -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: hpc/T10138 Related Tickets: | Blocking: | Differential Revisions: Phab:D771 -------------------------------------+------------------------------------- Changes (by dalaing): * differential: Phab:D766 => Phab:D771 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 23:28:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 23:28:18 -0000 Subject: [GHC] #10215: Optimizer has bugs regarding handling of -0.0 Message-ID: <045.bec2708cfecaad6939bf692a32bcb7aa@haskell.org> #10215: Optimizer has bugs regarding handling of -0.0 -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #9238 Differential Revisions: | -------------------------------------+------------------------------------- This is most likely related to https://ghc.haskell.org/trac/ghc/ticket/9238 Perhaps it can be merged into that if it is indeed the case, though it'd be good for an expert to take a look and make sure first that the culprit is indeed the same. In any case, the program in this ticket can at least serve as a test-case. I observed this on 7.8.3; though I suspect the same holds in the just released 7.10.1 as well. For the following program: {{{#!hs testF :: Float -> Bool testF x = x == 0 && not (isNegativeZero x) testD :: Double -> Bool testD x = x == 0 && not (isNegativeZero x) main :: IO () main = do print $ testF (-0.0) print $ testD (-0.0) }}} If I compile with no optimizations, then I get the correct answers: {{{ $ /bin/rm -f a.hi a.o a; ghc -O0 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... False False }}} But if I turn optimizations on, then I get: {{{ $ /bin/rm -f a.hi a.o a; ghc -O2 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... True True }}} which is just plain wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 29 23:35:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Mar 2015 23:35:39 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.08ed5d17db213708e37fe2fb686dab1c@haskell.org> #9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7858, #9451 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lerkok): Similar issue, and perhaps exactly the same bug: https://ghc.haskell.org/trac/ghc/ticket/10215#ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 04:11:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 04:11:53 -0000 Subject: =?utf-8?b?W0dIQ10gIzEwMjE2OiBBbGxvdyBhcnIg4oinIChmaXJzdCDiiKgg?= =?utf-8?q?=28***=29=29_as_minimal_definition_of_Arrow_instance?= Message-ID: <048.64b271a00a46843da0df000240882f80@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 06:26:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 06:26:17 -0000 Subject: [GHC] #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect In-Reply-To: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> References: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> Message-ID: <061.bc6728fdb7f815487723ac084d698a1b@haskell.org> #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect -------------------------------------+------------------------------------- Reporter: bmjames | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 06:29:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 06:29:02 -0000 Subject: [GHC] #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect In-Reply-To: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> References: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> Message-ID: <061.52395b583ff269d3260c9d2520d5ba8e@haskell.org> #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect -------------------------------------+------------------------------------- Reporter: bmjames | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D772 -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch * differential: => Phab:D772 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 07:22:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 07:22:32 -0000 Subject: [GHC] #10212: The testsuite cleans up hpc files, even if they are part of a test. In-Reply-To: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> References: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> Message-ID: <061.c0d9629d75fbdf575d3eacf5d82bf73d@haskell.org> #10212: The testsuite cleans up hpc files, even if they are part of a test. -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: hpc/T10138 Related Tickets: | Blocking: | Differential Revisions: Phab:D771 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"e24f638158f96f80e476000cd7ce8555987d84f2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e24f638158f96f80e476000cd7ce8555987d84f2" Renames some files to help with validation cleanup (#10212) Test Plan: validate twice Reviewed by: thomie Differential Revision: https://phabricator.haskell.org/D771 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 07:23:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 07:23:12 -0000 Subject: [GHC] #10212: The testsuite cleans up hpc files, even if they are part of a test. In-Reply-To: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> References: <046.be91c8cde816df989ab3ecc8f50498ce@haskell.org> Message-ID: <061.f57c37d990bff6a349ab8e4340ae3b19@haskell.org> #10212: The testsuite cleans up hpc files, even if they are part of a test. -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: hpc/T10138 Related Tickets: | Blocking: | Differential Revisions: Phab:D771 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 08:05:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 08:05:44 -0000 Subject: [GHC] #10217: Provide link to GPG signature on download page. Message-ID: <042.3be3cfd04f796daabfe8f3ac5fc1b22c@haskell.org> #10217: Provide link to GPG signature on download page. -------------------------------------+------------------------------------- Reporter: f-a | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple Documentation | Type of failure: Documentation Keywords: GPG, | bug signature | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As now, in the section "Binary packages" of GHC download page, you can read: > SHA-256 hashes for all the binary distributions are available here. with a link to the hashes' file. It would be great to provide a link to the signature of this file too, i.e.: > SHA-256 hashes for all the binary distributions are available here[link] (GPG signature available here[link], signed with key ). Hashes and Signatures are advertised in the mailing list release post, but I guess it would be nice for clarity's sake having them on the download page too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 08:11:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 08:11:46 -0000 Subject: [GHC] #10217: Provide link to GPG signature on download page. In-Reply-To: <042.3be3cfd04f796daabfe8f3ac5fc1b22c@haskell.org> References: <042.3be3cfd04f796daabfe8f3ac5fc1b22c@haskell.org> Message-ID: <057.65201f9f2069299f8f1c2b98d8480d9e@haskell.org> #10217: Provide link to GPG signature on download page. -------------------------------------+------------------------------------- Reporter: f-a | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: Resolution: | Keywords: GPG, Operating System: Unknown/Multiple | signature Type of failure: Documentation | Architecture: bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by f-a): * version: 7.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 08:22:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 08:22:16 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.4ff5e585c1e79c4e99fb72612bd52249@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317, #9159 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"de1160be047790afde4ec76de0a81ba3be0c73fa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="de1160be047790afde4ec76de0a81ba3be0c73fa" Refactor the story around switches (#10137) This re-implements the code generation for case expressions at the Stg ? Cmm level, both for data type cases as well as for integral literal cases. (Cases on float are still treated as before). The goal is to allow for fancier strategies in implementing them, for a cleaner separation of the strategy from the gritty details of Cmm, and to run this later than the Common Block Optimization, allowing for one way to attack #10124. The new module CmmSwitch contains a number of notes explaining this changes. For example, it creates larger consecutive jump tables than the previous code, if possible. nofib shows little significant overall improvement of runtime. The rather large wobbling comes from changes in the code block order (see #8082, not much we can do about it). But the decrease in code size alone makes this worthwhile. ``` Program Size Allocs Runtime Elapsed TotalMem Min -1.8% 0.0% -6.1% -6.1% -2.9% Max -0.7% +0.0% +5.6% +5.7% +7.8% Geometric Mean -1.4% -0.0% -0.3% -0.3% +0.0% ``` Compilation time increases slightly: ``` -1 s.d. ----- -2.0% +1 s.d. ----- +2.5% Average ----- +0.3% ``` The test case T783 regresses a lot, but it is the only one exhibiting any regression. The cause is the changed order of branches in an if-then-else tree, which makes the hoople data flow analysis traverse the blocks in a suboptimal order. Reverting that gets rid of this regression, but has a consistent, if only very small (+0.2%), negative effect on runtime. So I conclude that this test is an extreme outlier and no reason to change the code. Differential Revision: https://phabricator.haskell.org/D720 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 08:22:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 08:22:16 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.599586224ecd69926a457327debadd27@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, | Differential Revisions: #9661,#10137 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"de1160be047790afde4ec76de0a81ba3be0c73fa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="de1160be047790afde4ec76de0a81ba3be0c73fa" Refactor the story around switches (#10137) This re-implements the code generation for case expressions at the Stg ? Cmm level, both for data type cases as well as for integral literal cases. (Cases on float are still treated as before). The goal is to allow for fancier strategies in implementing them, for a cleaner separation of the strategy from the gritty details of Cmm, and to run this later than the Common Block Optimization, allowing for one way to attack #10124. The new module CmmSwitch contains a number of notes explaining this changes. For example, it creates larger consecutive jump tables than the previous code, if possible. nofib shows little significant overall improvement of runtime. The rather large wobbling comes from changes in the code block order (see #8082, not much we can do about it). But the decrease in code size alone makes this worthwhile. ``` Program Size Allocs Runtime Elapsed TotalMem Min -1.8% 0.0% -6.1% -6.1% -2.9% Max -0.7% +0.0% +5.6% +5.7% +7.8% Geometric Mean -1.4% -0.0% -0.3% -0.3% +0.0% ``` Compilation time increases slightly: ``` -1 s.d. ----- -2.0% +1 s.d. ----- +2.5% Average ----- +0.3% ``` The test case T783 regresses a lot, but it is the only one exhibiting any regression. The cause is the changed order of branches in an if-then-else tree, which makes the hoople data flow analysis traverse the blocks in a suboptimal order. Reverting that gets rid of this regression, but has a consistent, if only very small (+0.2%), negative effect on runtime. So I conclude that this test is an extreme outlier and no reason to change the code. Differential Revision: https://phabricator.haskell.org/D720 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 08:22:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 08:22:16 -0000 Subject: [GHC] #8082: Ordering of assembly blocks affects performance In-Reply-To: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> References: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> Message-ID: <063.06e3f64c9c4921393820483ec901ce54@haskell.org> #8082: Ordering of assembly blocks affects performance -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"de1160be047790afde4ec76de0a81ba3be0c73fa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="de1160be047790afde4ec76de0a81ba3be0c73fa" Refactor the story around switches (#10137) This re-implements the code generation for case expressions at the Stg ? Cmm level, both for data type cases as well as for integral literal cases. (Cases on float are still treated as before). The goal is to allow for fancier strategies in implementing them, for a cleaner separation of the strategy from the gritty details of Cmm, and to run this later than the Common Block Optimization, allowing for one way to attack #10124. The new module CmmSwitch contains a number of notes explaining this changes. For example, it creates larger consecutive jump tables than the previous code, if possible. nofib shows little significant overall improvement of runtime. The rather large wobbling comes from changes in the code block order (see #8082, not much we can do about it). But the decrease in code size alone makes this worthwhile. ``` Program Size Allocs Runtime Elapsed TotalMem Min -1.8% 0.0% -6.1% -6.1% -2.9% Max -0.7% +0.0% +5.6% +5.7% +7.8% Geometric Mean -1.4% -0.0% -0.3% -0.3% +0.0% ``` Compilation time increases slightly: ``` -1 s.d. ----- -2.0% +1 s.d. ----- +2.5% Average ----- +0.3% ``` The test case T783 regresses a lot, but it is the only one exhibiting any regression. The cause is the changed order of branches in an if-then-else tree, which makes the hoople data flow analysis traverse the blocks in a suboptimal order. Reverting that gets rid of this regression, but has a consistent, if only very small (+0.2%), negative effect on runtime. So I conclude that this test is an extreme outlier and no reason to change the code. Differential Revision: https://phabricator.haskell.org/D720 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 08:23:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 08:23:39 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.21272fa281ae0ef0351cc3f5331108a8@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317, #9159 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Pushed this now, ready to tackle any fallout. Now on to implementing a fix for #10124. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 08:46:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 08:46:28 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> Message-ID: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: yes | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- My co-worker and I have spent almost two weeks tracking down this bug. We have finally produced a reasonably small test case... please take a look: https://github.com/yongqli/ghctestcase Under certain circumstances GHC generates incorrect code which goes into <>. When you compile and run the project without profiling and with eager black-holing, it will throw <> and exit. If you compile either without eager black-holing or with profiling, it will run correctly. See setup.hs for further details. This bug can be delicate to trigger, inlining certain things will prevent it from occurring. However, we've encountered this in production, and it is much harder to work-around in an actual project. We've had to resort to inlining every function in the affected module, which slows down compilation considerably. We've found that this bug triggers on 7.10.1 and 7.8.4. The test case will only compile on 7.10.1. Please let me know if there are any questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 09:56:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 09:56:25 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.c1c58160073d97d652a7d0488c25b554@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by dalaing): How would we resolve things like {{{#!hs type instance Testing (f :>: _) = MyType f type instance Testing (_ :>: g) = MyType g }}} and other such collisions? I'm pretty new to GHC - is there an existing resolution order from elsewhere that could be borrowed for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 10:40:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 10:40:04 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.d3d1c96489de02d1f2cba47664f6fb25@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, | Differential Revisions: #9661,#10137 | -------------------------------------+------------------------------------- Comment (by nomeata): With the above refactoring in place, it should be easier now to implement this on the Cmm level. I had a quick look, but I?m a bit lost with Cmm here (conditionals vs. boolean ops etc.). If someone can tell me what the correct Cmm code should be for, say, the example from comment:10, that?d be helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 11:04:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 11:04:24 -0000 Subject: [GHC] #10211: Validate fails in RTS tests on Mac OS X In-Reply-To: <046.ceeba31edc5276171ff0db279007810e@haskell.org> References: <046.ceeba31edc5276171ff0db279007810e@haskell.org> Message-ID: <061.60536162103caaa3a341020d3e0c4340@haskell.org> #10211: Validate fails in RTS tests on Mac OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9389 | rts/linker_unload | Blocking: | Differential Revisions: Phab:D765 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"c37ee4a8009b438f86b1ca6df10901d7f783b4f0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c37ee4a8009b438f86b1ca6df10901d7f783b4f0" Remove an unused include that doesn't exist on OS X (#10211) Differential Revision: https://phabricator.haskell.org/D765 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 12:19:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 12:19:03 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.68dcaa23878f3b97ca65335aba374c27@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 12:35:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 12:35:24 -0000 Subject: [GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) In-Reply-To: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> References: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> Message-ID: <060.7f56a7e3ede84e8a39cad82b06cc9c36@haskell.org> #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: Look in the `compiler/main` directory. Grep for `ForceRecomp`. Try to figure out what's going on (will take you a while). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 12:37:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 12:37:11 -0000 Subject: [GHC] #8981: ghc-pkg complains about missing haddock interface files In-Reply-To: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> References: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> Message-ID: <067.48433c04dba6719b0c54b5daf8fad17d@haskell.org> #8981: ghc-pkg complains about missing haddock interface files -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: ghc-pkg | Version: 7.8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: ghc-pkg => newcomer Comment: Look at the `utils/ghc-pkg` directory. A solution might need coordination with cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 12:46:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 12:46:20 -0000 Subject: [GHC] #8403: Pretty-printing of long types In-Reply-To: <047.792ac96369079bc46b579fe906221406@haskell.org> References: <047.792ac96369079bc46b579fe906221406@haskell.org> Message-ID: <062.0622ba4d0c66ba84a011adaf4bc9cf08@haskell.org> #8403: Pretty-printing of long types -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9428 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: Might not be easy, but I think a fix is to be found in this single file: `compiler/utils/Pretty.hs`. For historical reasons, there's also a copy in `libraries/pretty`. See https://github.com/haskell/pretty/issues/1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 12:46:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 12:46:50 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.ca8fb24e17288fee38954d553bea98dd@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9324 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 13:05:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 13:05:17 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.dc0e52f589391e97bd9a732ccfc71a6c@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by jstolarek): I always imagined that `_` will be instantiated internally to a fresh type variable. This means that this feature would mostly affect the parser and renamer and by the time you reach the point when your example collision is checked (`FamInst.checkForConflicts`, called from `FamInst.checkFamInstConsistency`) the example code will look like: {{{#!hs type instance Testing (f :>: a_1234) = MyType f type instance Testing (a_5678 :>: g) = MyType g }}} where `a_1234` and `a_5678` are fresh type variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 13:07:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 13:07:04 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.55fb26a5b9a4e2617d45683db5f6fdd0@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: See comment:5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 13:07:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 13:07:47 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.8cefdf21d0256874bc25e6355b935def@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Feuerbach): * cc: roma@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 13:11:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 13:11:23 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.a3ee44df1c7955d092f30c734a89dbda@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature request | Status: infoneeded Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 15:03:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 15:03:20 -0000 Subject: [GHC] #10219: ghc -x hspp test.hspp: cannot compile to this file to desired target Message-ID: <045.d6f2eae1532a74744c59810b804a5668@haskell.org> #10219: ghc -x hspp test.hspp: cannot compile to this file to desired target -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 18:28:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 18:28:29 -0000 Subject: [GHC] #10219: ghc -x hspp test.hspp: cannot compile to this file to desired target In-Reply-To: <045.d6f2eae1532a74744c59810b804a5668@haskell.org> References: <045.d6f2eae1532a74744c59810b804a5668@haskell.org> Message-ID: <060.b8dcb3c84bfd37bc7caba7e1525d94a9@haskell.org> #10219: ghc -x hspp test.hspp: cannot compile to this file to desired target -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.10.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 Revisions: Phab:D776 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D776 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 18:30:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 18:30:08 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.64e90f44fd0bf83ae35423660adf2669@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): This would also necessitate a change to the MINIMAL pragma, I suppose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 18:30:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 18:30:54 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.502d9d00cf4615d1c1c8867c9ab960d4@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): No objection here, BTW. This makes `Arrow`'s internals far more symmetrical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 18:32:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 18:32:57 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.829c2d8e82273739c4bc93588076110b@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Comment (by javran): almost done patching up GHC for better suggestions. What about adding options like -no-rtsopts-suggestions? I don't see much discussion here. I think The bug described in OP will be solved with the current patch and we should open another ticket for adding new options. @rwbarton would you mind opening another ticket and give more details about the option you've proposed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 19:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 19:00:27 -0000 Subject: [GHC] #10204: Odd interaction between rank-2 types and type families In-Reply-To: <047.40c7f4223ed199be95aee7f3ef8794b7@haskell.org> References: <047.40c7f4223ed199be95aee7f3ef8794b7@haskell.org> Message-ID: <062.b2d2ddb0fcbe5d90a5ee2d481dd8eb8d@haskell.org> #10204: Odd interaction between rank-2 types and type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Description changed by diatchki: Old description: > Type inference does work as expected, when a rank-2 type has type-family > constraint. Consider the following program: > > {{{#!hs > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE Rank2Types #-} > > type family F a > > f :: (forall s. (F s ~ Int) => s -> b) -> b > f _ = undefined > > k :: s -> Char > k = undefined > > example :: Bool > example = const True (f k) > }}} > > It is rejected with the following error: > > {{{ > Couldn't match type ?b0? with ?Char? > ?b0? is untouchable > inside the constraints (F s ~ Int) > bound by a type expected by the context: (F s ~ Int) => s -> b0 > at bug.hs:13:23-25 > Expected type: s -> b0 > Actual type: s -> Char > In the first argument of ?f?, namely ?k? > In the second argument of ?const?, namely ?(f k)? > }}} > > This is unexpected because the result of `f` should be the same as > the result of its parameter, and we know the exact type of the parameter, > namely `Char`. New description: Type inference does not work as expected, when a rank-2 type has type- family constraint. Consider the following program: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} type family F a f :: (forall s. (F s ~ Int) => s -> b) -> b f _ = undefined k :: s -> Char k = undefined example :: Bool example = const True (f k) }}} It is rejected with the following error: {{{ Couldn't match type ?b0? with ?Char? ?b0? is untouchable inside the constraints (F s ~ Int) bound by a type expected by the context: (F s ~ Int) => s -> b0 at bug.hs:13:23-25 Expected type: s -> b0 Actual type: s -> Char In the first argument of ?f?, namely ?k? In the second argument of ?const?, namely ?(f k)? }}} This is unexpected because the result of `f` should be the same as the result of its parameter, and we know the exact type of the parameter, namely `Char`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 19:01:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 19:01:38 -0000 Subject: [GHC] #10204: Odd interaction between rank-2 types and type families In-Reply-To: <047.40c7f4223ed199be95aee7f3ef8794b7@haskell.org> References: <047.40c7f4223ed199be95aee7f3ef8794b7@haskell.org> Message-ID: <062.20ee8ff6387e0c44d658741cfac2399e@haskell.org> #10204: Odd interaction between rank-2 types and type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Description changed by diatchki: Old description: > Type inference does not work as expected, when a rank-2 type has type- > family constraint. Consider the following program: > > {{{#!hs > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE Rank2Types #-} > > type family F a > > f :: (forall s. (F s ~ Int) => s -> b) -> b > f _ = undefined > > k :: s -> Char > k = undefined > > example :: Bool > example = const True (f k) > }}} > > It is rejected with the following error: > > {{{ > Couldn't match type ?b0? with ?Char? > ?b0? is untouchable > inside the constraints (F s ~ Int) > bound by a type expected by the context: (F s ~ Int) => s -> b0 > at bug.hs:13:23-25 > Expected type: s -> b0 > Actual type: s -> Char > In the first argument of ?f?, namely ?k? > In the second argument of ?const?, namely ?(f k)? > }}} > > This is unexpected because the result of `f` should be the same as > the result of its parameter, and we know the exact type of the parameter, > namely `Char`. New description: Type inference does not work as expected, when a rank-2 type has a type- family constraint. Consider the following program: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} type family F a f :: (forall s. (F s ~ Int) => s -> b) -> b f _ = undefined k :: s -> Char k = undefined example :: Bool example = const True (f k) }}} It is rejected with the following error: {{{ Couldn't match type ?b0? with ?Char? ?b0? is untouchable inside the constraints (F s ~ Int) bound by a type expected by the context: (F s ~ Int) => s -> b0 at bug.hs:13:23-25 Expected type: s -> b0 Actual type: s -> Char In the first argument of ?f?, namely ?k? In the second argument of ?const?, namely ?(f k)? }}} This is unexpected because the result of `f` should be the same as the result of its parameter, and we know the exact type of the parameter, namely `Char`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 19:03:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 19:03:04 -0000 Subject: [GHC] #8830: internal error: Misaligned section: 18206e5b on Windows In-Reply-To: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> References: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> Message-ID: <062.49a2fc2e7bc38070beec202b25b88f86@haskell.org> #8830: internal error: Misaligned section: 18206e5b on Windows -------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: infoneeded Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------- Comment (by mtolly): This appears to specifically happen when you link in static C libraries during TH on Windows. MinGW's linker will automatically prefer static libraries over dynamic ones if it finds them, so you can work around it by only using dynamic libraries. Here's what I did: I have an executable that uses libsndfile, and its Haskell binding hsndfile, and also uses TH. On Windows XP with MinGW/MSYS, I compiled and installed libsndfile and its dependencies, and installed hsndfile, but when it got to the module that needs TH, I got: {{{ Loading package hsndfile-0.7.1 ... ghc.exe: internal error: Misaligned section .eh_frame: 0d035673 (GHC version 7.8.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} So, I went into the lib/ folder I had installed the C libraries into, and deleted all the static libraries (like libsndfile.a), leaving only e.g. libsndfile.dll.a and libsndfile.la, plus libsndfile-1.dll in my bin/ folder. Then I recompiled all the Haskell packages that used C libs (hsndfile and everything on top of it). Tried to compile the executable again, and it complained of not being able to find "sndfile.dll". So I just copied libsndfile-1.dll to sndfile.dll, and then it compiled and ran fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 19:47:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 19:47:56 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.1779f6c62d0693cb8a32d3fd997160d2@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jonsterling): * cc: core-libraries-committee@? (added) Comment: We (PivotCloud) are running up against this problem currently (it is causing live-locking in our production code) and are curious if a patch would be accepted to make the change described in the ticket (i.e. change the case statement to a let binding). Incidentally, in Simon Marlowe's book, he explicitly mentions that one should use a lazy let here instead of a case statement, but somehow this did not make it into the actual implementation of TQueue. See http://chimera.labs.oreilly.com/books/1230000000929/ch10.html#CO37-2 Also, I don't know how releases for STM work---is it plausible that we could fix this quickly and get out a new version of STM, or would a better path forward for our immediate need be to just make a custom (copy-and- paste) version of TQueue with this fix? We are happy to submit a patch in either case. Thanks! Jon Sterling & Lars Kuhtz PivotCloud Inc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 20:23:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 20:23:05 -0000 Subject: [GHC] #10220: Imports from `.hspp` and `.hscpp` files not loaded in --make mode Message-ID: <045.620241abff5b66e6139f3b60e61ef101@haskell.org> #10220: Imports from `.hspp` and `.hscpp` files not loaded in --make mode -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 20:55:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 20:55:52 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.b46535c4b48b3c6bc00b0c3846aba0d8@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by dalaing): I thought about this a little last night and realised that the resolution should be the same as for unused type variables. Your comment confirms that and gives a few hints on where to get started - so thanks heaps! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 21:03:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 21:03:17 -0000 Subject: [GHC] #10220: Imports from `.hspp` and `.hscpp` files not loaded in --make mode In-Reply-To: <045.620241abff5b66e6139f3b60e61ef101@haskell.org> References: <045.620241abff5b66e6139f3b60e61ef101@haskell.org> Message-ID: <060.e618529ea618b8a388b7aade3813eb34@haskell.org> #10220: Imports from `.hspp` and `.hscpp` files not loaded in --make mode -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D778 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D778 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 22:03:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 22:03:52 -0000 Subject: [GHC] #10221: LLVM does not work on OSX Message-ID: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> #10221: LLVM does not work on OSX -------------------------------------------+---------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+---------------------------- I can't seem to be able to use the LLVM backend on OSX. I get the error: {{{ error: unknown directive .macosx_version_min 10, 0 ^ : Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) : ghc: phase `Clang (Assembler)' failed (exitcode = 1) }}} This is on GHC 7.10.1 {{{ % clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix yongqli at auxiliary ~/secrets/projects/stocvol % opt --version LLVM (http://llvm.org/): LLVM version 3.5.1 Optimized build with assertions. Built Jan 15 2015 (18:24:46). Default target: x86_64-apple-darwin14.1.0 Host CPU: core-avx2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 22:33:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 22:33:16 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.32f27898065a88ca740d7864cec0c7af@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (LLVM) Comment: Please supply the smallest program that fails, with the command you use to compile it. See [wiki:ReportABug] for details. Please note that ghc doesn't have very many people working on fixing [https://ghc.haskell.org/trac/ghc/query?status=!closed&os=MacOS+X OSX specific bugs] at the moment. Volunteers welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 22:37:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 22:37:04 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.02e5a1fd01305084dbdd025deb0b661d@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I have seen this reported before, I think it is due to using a third-party gcc (to compile llc's output) together with an Apple llc, or something like that. Smallest program that fails is most likely `main = return ()`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 22:39:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 22:39:46 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.9fbd7bb5bb4910265ab7e0724344a83e@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): I've just uninstall all gcc from my system but it still happens. {{{ % gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 22:43:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 22:43:57 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.8247d9a8409ce5c6021c1d745e9516d5@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Can you run ghc with `-v` and copy the failing invocation here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 22:53:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 22:53:15 -0000 Subject: [GHC] #9225: Missing syntax error for package qualified import with version number In-Reply-To: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> References: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> Message-ID: <060.40cb2da9f47d0ad5d7b0b99384f86340@haskell.org> #9225: Missing syntax error for package qualified import with version number -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | Blocking: Blocked By: | Differential Revisions: Phab:D755 Related Tickets: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5971ad56afbdadc9af1cf9e8d708783d2fddbd95/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5971ad56afbdadc9af1cf9e8d708783d2fddbd95" Syntax check package-qualified imports (#9225) Version numbers are not allowed in the package name of a package-qualified import. Reviewed By: austin, ezyang Differential Revision: https://phabricator.haskell.org/D755 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 22:54:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 22:54:32 -0000 Subject: [GHC] #9225: Missing syntax error for package qualified import with version number In-Reply-To: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> References: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> Message-ID: <060.3f4f95a3afdb9bb0ea21c82088e1bf57@haskell.org> #9225: Missing syntax error for package qualified import with version number -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 (Parser) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | parser/should_fail/T9225 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D755 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => parser/should_fail/T9225 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 22:54:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 22:54:33 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.8e4df0fce82242f2088ecae1ee32fb76@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): {{{ % cabal build -v2 Using a sandbox located at /Users/yongqli/Documents/ghctestcase/.cabal- sandbox Reading available packages... Reading installed packages... /Applications/ghc-7.10.1.app/Contents/bin/ghc-pkg dump '--package- db=/Users/yongqli/Documents/ghctestcase/.cabal-sandbox/x86_64-osx- ghc-7.10.1-packages.conf.d' -v0 /Applications/ghc-7.10.1.app/Contents/bin/ghc --print-libdir Found no modified add-source deps. Component build order: executable 'ModelTest' creating dist/build creating dist/build/autogen Building mlmodel-0.1.0.0... /Applications/ghc-7.10.1.app/Contents/bin/ghc-pkg init dist/package.conf.inplace Preprocessing executable 'ModelTest' for mlmodel-0.1.0.0... Building executable ModelTest... creating dist/build/ModelTest creating dist/build/ModelTest/ModelTest-tmp /Applications/ghc-7.10.1.app/Contents/bin/ghc --make -no-link -fbuilding- cabal-package -O -j8 -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build/ModelTest/ModelTest-tmp -odir dist/build/ModelTest /ModelTest-tmp -hidir dist/build/ModelTest/ModelTest-tmp -stubdir dist/build/ModelTest/ModelTest-tmp -i -idist/build/ModelTest/ModelTest-tmp -isrc -idist/build/autogen -Idist/build/autogen -Idist/build/ModelTest /ModelTest-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide- all-packages -no-user-package-db -package-db /Users/yongqli/Documents/ghctestcase/.cabal-sandbox/x86_64-osx- ghc-7.10.1-packages.conf.d -package-db dist/package.conf.inplace -package- id base-4.8.0.0-9015e10d2b2b0f71f570c3f2bbe09c8a -package-id linear-1.18.0.1-cbd55feca9eb96b48a763e434624a836 -package-id mtl-2.2.1-9986828fc95bc8459870303efaabd81e -package-id vector-0.10.12.3-46b824313b7a6e427d3957d73978f382 -package-id vector-th- unbox-0.2.1.2-103bf73b42f980755b23fd8b8b31c5b4 -XHaskell2010 -XArrows -XBangPatterns -XConstraintKinds -XEmptyDataDecls -XFlexibleContexts -XFlexibleInstances -XFunctionalDependencies -XGADTs -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XRankNTypes -XScopedTypeVariables -XTemplateHaskell -XTypeFamilies -XTypeOperators src/Main.hs -O1 -rtsopts -threaded -fllvm -feager-blackholing [1 of 3] Compiling Stats.Types ( src/Stats/Types.hs, dist/build/ModelTest/ModelTest-tmp/Stats/Types.o ) /var/folders/vg/650_vlys0sv_dkzdclr2_68r0000gn/T/ghc21346_0/ghc21346_6.s:3:2: error: unknown directive .macosx_version_min 10, 0 ^ : Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) : ghc: phase `Clang (Assembler)' failed (exitcode = 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 22:56:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 22:56:25 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.2d40433cd40f0d849a4e7a2a81d0bdf4@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I mean run ghc with `-v`, i.e., run cabal with `--ghc-option=-v`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 23:11:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 23:11:27 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.1e244637208328e5127a6c9809036fdc@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: 5144 | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dmcclean): Is it true that support for this didn't make it into 7.10? That looks to be the case, although it also looks to be the case that it did sneak in to the documentation: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/syntax- extns.html#pattern-synonyms But my attempt to use the bidirectional syntax: {{{ {-# LANGUAGE PatternSynonyms #-} data AugmentedRational = Exact' Integer Rational | Approximate (forall a.Floating a => a) pattern Exact z q <- Exact' z q where Exact z q | q == 0 = Exact' 0 0 | otherwise = Exact' z q }}} is rejected with {{{ parse error on input `where' }}} By contrast, the 7.8.4 docs don't list this syntax, see https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/syntax- extns.html#pattern-synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 23:18:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 23:18:10 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.351c0781e70cea2a8308ca885e23f4c0@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: 5144 | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dmcclean): * cc: douglas.mcclean@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 23:21:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 23:21:16 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.6a6eda0e1e751322f2ed56133dd98a89@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: 5144 | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): dmcclean, I was able to compile your program with ghc-7.10.0.20150123, though I had to add the RankNTypes language extension as well; can you double check? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 30 23:23:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Mar 2015 23:23:11 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.0a89385149088a070d236c3025bd8c13@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: 5144 | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): There is definitely support in GHC 7.10 for bidirectional pattern synonyms. Unfortunately I can't reproduce your problem, can you post a larger example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 02:01:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 02:01:10 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally In-Reply-To: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> References: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> Message-ID: <063.70f9e0c24e2dcc8747c356a21383009b@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10188 | -------------------------------------+------------------------------------- Changes (by Kinokkory): * owner: => Kinokkory * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 02:53:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 02:53:39 -0000 Subject: [GHC] #10222: Data.Foldable should have genericLength Message-ID: <043.c27187ff1670ff2de9c5e5a2d1dd1b1e@haskell.org> #10222: Data.Foldable should have genericLength -------------------------------------+------------------------------------- Reporter: uznx | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The "length" function in Data.Foldable has its return type hardcoded to "Int". There should also be a genericLength function which can return any Num type, similar to Data.List.genericLength. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 08:04:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 08:04:31 -0000 Subject: [GHC] #10222: Data.Foldable should have genericLength In-Reply-To: <043.c27187ff1670ff2de9c5e5a2d1dd1b1e@haskell.org> References: <043.c27187ff1670ff2de9c5e5a2d1dd1b1e@haskell.org> Message-ID: <058.6bd287b908764c374290fb389cdbebd6@haskell.org> #10222: Data.Foldable should have genericLength -------------------------------------+------------------------------------- Reporter: uznx | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * resolution: => invalid * status: new => closed * component: libraries/base => Core Libraries Comment: Please argue your case on the libraries mailinglist first, and add a link to the thread here. See https://wiki.haskell.org/Library_submissions. When your proposal is accepted, you can reopen this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 08:22:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 08:22:31 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.d862b8cf5fd19c8c67ad3bfc09d17a03@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, | Differential Revisions: #9661,#10137 | -------------------------------------+------------------------------------- Comment (by nomeata): Hmm, given the example from comment:10, we currently generate this code: {{{ block_c3S3_info: _c3S3: movq 7(%rbx),%rax cmpq $10,%rax jb _u3Si _u3Sj: cmpq $11,%rax jb _c3Sh _u3Sk: cmpq $32,%rax jne _c3Se _c3Sh: movl $GHC.Types.True_closure+2,%ebx addq $8,%rbp jmp *(%rbp) _c3S7: movl $myIsSpace_rkB_closure,%ebx jmp *-8(%r13) _c3Se: movl $GHC.Types.False_closure+1,%ebx addq $8,%rbp jmp *(%rbp) _u3Si: cmpq $9,%rax jb _c3Se jmp _c3Sh }}} while my code now generates {{{ _c3S3: movq 7(%rbx),%rax cmpq $32,%rax setne %bl movzbl %bl,%ebx cmpq $10,%rax setne %cl movzbl %cl,%ecx andq %rbx,%rcx cmpq $9,%rax setne %al movzbl %al,%eax andq %rcx,%rax testq %rax,%rax jne _c3Se _c3Sh: movl $GHC.Types.True_closure+2,%ebx addq $8,%rbp jmp *(%rbp) _c3S7: movl $myIsSpace_rkB_closure,%ebx jmp *-8(%r13) _c3Se: movl $GHC.Types.False_closure+1,%ebx addq $8,%rbp jmp *(%rbp) .size myIsSpace_rkB_info, .-myIsSpace_rkB_info }}} But not even this simple microbenchmark {{{ main :: IO () main = x `seq` return () where x = length $ filter myIsSpace $ concatMap (replicate 100000000) $ ['\001'..'z'] }}} shows a change in performance. bgamari, is that expected? Is it just that the assembly (generated from {{{ if ((_s3Rr::I64 != 9) & (_s3Rr::I64 != 10) & (_s3Rr::I64 != 32) != 0) goto c3Se; else goto c3Sh; }}} is too bad, or is this not a test case where this will help a lot? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 08:50:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 08:50:28 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.348e6d38dcf6c2c5b87d3afbee077cdb@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dalaing): Any thoughts on whether I should - just add the missing space in - work out the maximum width of the "no." column and pad things out to suit? Both are pretty doable, although I've got the first one more or less ready to go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 09:01:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 09:01:11 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.1cbf9dcb2b415478c6254ed744067cb0@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8647 #9818 | Test Case: | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"995e8c1c8692b60c907c7d2ccea179d52ca8e69e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="995e8c1c8692b60c907c7d2ccea179d52ca8e69e" Drop old integer-gmp-0.5 from GHC source tree This completes what c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a (#9281) started. `integer-gmp-1.0` was added as an additional `libraries/integer-gmp2` folder while retaining the ability to configure GHC w/ the old `integer-gmp-0.5` to have a way back, and or the ability to easily switch between old/new `integer-gmp` for benchmark/debugging purposes. This commit removes the old `libraries/integer-gmp` folder and moves `libraries/integer-gmp2` into its place, while removing any mentions of "gmp2" as well as the to support two different `integer-gmp` packages in GHC's source-tree. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D769 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 09:02:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 09:02:01 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.df5f442abb5ac3d1b10d95ad50922113@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): * If you calculate the maximum width of the "no." column, then writing a test will be easier. Otherwise you'd need a test with over >10^4 or 10^5 cost centres, which might need to run for a long time? Just do what you think is reasonable, maybe no extra test is needed. * To be sure: the line I referenced above is only for the header. The function `logCCS` needs to be updated as well. * I think all the .prof.sample files in the output will need to be updated afterwards. You might want to make sure they are up-to-date before making any changes. See [wiki:Building/RunningTests/Updating]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 09:13:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 09:13:41 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.f4cca17e5bc115c3ab888368371b3b05@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D779 -------------------------------------+------------------------------------- Changes (by dalaing): * differential: => Phab:D779 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 09:15:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 09:15:51 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.91fedc6250d5898cc6aecaaf0f39220f@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D779 -------------------------------------+------------------------------------- Comment (by dalaing): I've updated a few things, including logCCS. Some of the constants in the file / formatting string seemed to be out by 1. I'm not sure a new test is needed, although I definitely need to update the .prof.sample files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 10:11:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 10:11:23 -0000 Subject: [GHC] #7563: Passing -C flag causes the 'impossible' to happen In-Reply-To: <048.c01bd69ad3c4848bd1107d9068a46664@haskell.org> References: <048.c01bd69ad3c4848bd1107d9068a46664@haskell.org> Message-ID: <063.5ba9ac883658df1efccd585f2a7ac676@haskell.org> #7563: Passing -C flag causes the 'impossible' to happen -------------------------------------------------+------------------------- Reporter: jstolarek | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Test Case: T7563 Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Comment (by Thomas Miedema ): In [changeset:"9e073ce41ff471d0b734ace095ece2a3e4c02f68/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9e073ce41ff471d0b734ace095ece2a3e4c02f68" Explicitly check for -C on registerised build (#7563) Show a more descriptive error message. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D775 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 10:15:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 10:15:50 -0000 Subject: [GHC] #10219: ghc -x hspp test.hspp: cannot compile to this file to desired target In-Reply-To: <045.d6f2eae1532a74744c59810b804a5668@haskell.org> References: <045.d6f2eae1532a74744c59810b804a5668@haskell.org> Message-ID: <060.aae3f62c717e0eeed93277e846e2217b@haskell.org> #10219: ghc -x hspp test.hspp: cannot compile to this file to desired target -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.10.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 Revisions: Phab:D776 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"698186268d3846c9984798ab32f34f83f3c2337e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="698186268d3846c9984798ab32f34f83f3c2337e" Don't throw exception when start_phase==stop_phase (#10219) Just do nothing instead. This bug only shows up when using `-x hspp` in --make mode on registerised builds. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D776 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 10:18:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 10:18:12 -0000 Subject: [GHC] #10219: ghc -x hspp test.hspp: cannot compile this file to desired target (was: ghc -x hspp test.hspp: cannot compile to this file to desired target) In-Reply-To: <045.d6f2eae1532a74744c59810b804a5668@haskell.org> References: <045.d6f2eae1532a74744c59810b804a5668@haskell.org> Message-ID: <060.0c7f11dc3e94402d5625bd20597bac90@haskell.org> #10219: ghc -x hspp test.hspp: cannot compile this file to desired target -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | driver/T10219 Related Tickets: | Blocking: | Differential Revisions: Phab:D776 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => driver/T10219 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 14:03:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 14:03:55 -0000 Subject: [GHC] #7835: ghc --make: allow passign .cmm, .c and .hs files in one command line In-Reply-To: <045.a577cc725bc792da911b2a70e7dec6a8@haskell.org> References: <045.a577cc725bc792da911b2a70e7dec6a8@haskell.org> Message-ID: <060.715d53fd119d12277781d2edf626b709@haskell.org> #7835: ghc --make: allow passign .cmm, .c and .hs files in one command line -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | driver/T7835/T7835 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => driver/T7835/T7835 Comment: In commit c93e866869fba09c119ea5e99724fddaf335ed01: {{{ Author: Ian Lynagh <> Date: Tue Jul 30 22:11:31 2013 +0100 Add a test for #7835 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 14:29:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 14:29:36 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.d8b1b99eb019a57c5d7b75d0f5d3c679@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Phab:D768 Related Tickets: #10189 | -------------------------------------+------------------------------------- Comment (by goldfire): Looking more closely at this, I think this was not a bug in the parser, but in the pretty-printer. The pretty-printer prints type-level `:::` as `(':::)`, but it should be `'(:::)`, which is what is parsed. Normal type- level cons is parsed the same way, with the tick outside the parentheses. (Which I think is confusing, but that ship has sailed.) On the other hand, it does seem draconian to '''require''' the tick for cons, when `:` has no possible other interpretation as a type-level constant. So, considering this as a feature request, I think it's a good one. Thanks for the patch! Did you end up submitting a separate bug report for the pretty-printer? That's still outstanding, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 14:36:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 14:36:07 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally In-Reply-To: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> References: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> Message-ID: <063.d21529c1c0d5fa23521ff261140fc511@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10188 | -------------------------------------+------------------------------------- Comment (by goldfire): This is a hard call for me. While I agree that putting the tick inside the parens is better, I'm leery of having two different ways to say the same think, with no change in meaning. It just seems confusing. And, removing the current (outside-the-parens) notation would be a large disruption for little benefit. I vote: fix the pretty-printer to match the parser, but leave the parser alone. This makes me sad, but it seems better than the alternatives. By the way, also look at infix promoted alphanumeric constructors: {{{ data Foo = Bar Bool Bool type Baz = True '`Bar` False }}} Note where that tick goes. I hate it! But, I still vote against changing it. Just make sure the pretty-printer does the right thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 14:43:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 14:43:32 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.15d85543e93efa52d5d191daaaf363df@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I'm perhaps abusing the term "overlap". What I mean here is that GHC has two routes with which to satisfy a `Bar m m'` constraint. Let's rename variables in the global instance for clarity: `instance (BarFamily b b' ~ 'True) => Bar b b'`. During type inference, GHC has to solve a `Bar p q` constraint, for some `p` and some `q`. If, at this point during inference, it knows `p ~ m` and `q ~ m'`, GHC will prefer the local constraint `Bar m m'`. Otherwise, if we don't yet know enough about `p` and `q`, it will use the global instance and then require `BarFamily p q ~ 'True`. Even if we later learn that `p ~ m` and `q ~ m'`, it's too late to use the `Bar m m'` constraint. I do know that GHC "tries hard" to resolve equality constraints before class constraints, but ''guaranteeing'' that this happens may be impossible. So, you'll end up with situations like these. I'd be quite curious for Simon's input here. He's on holiday at the moment, but I'm sure he'll chime in ere too long. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 15:31:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 15:31:22 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.f353e1cae3c550dca60a61ae0d3a5d67@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): Ok, I've just taken a brief look and I can't off the top of my head remember why the reverse is strict inside the STM transaction. If the lazy version solves the problem and isn't any slower, we should use that. But it needs someone to run some benchmarks - I think I have a benchmark somewhere that I can dig up, but if anyone else want to do some quick measurements please go ahead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 18:07:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 18:07:19 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` Message-ID: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 18:17:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 18:17:16 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.e94c712dac6dc4b3d4fefc1169de24b7@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I vote to remove `-Rghc-timing` from this file. Note that it has to be removed from this file, and also somewhere(?) else. I currently put `GhcHcOpts =` in my `build.mk`s to make sure this output is squashed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 20:05:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 20:05:00 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.9cfdb4c8e033da623f299ef9a4ade671@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Phab:D783 filters out `-Rghc-timing` for `V=0` builds. I didn't make any changes to the default `V=1` build, as `-Rghc-timing` has been part of that default since at least the beginning of the century, some people might depend on it, and it could be useful for bug reports. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 21:09:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 21:09:26 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command In-Reply-To: <047.01134e82983fb263026aa29a14aa8897@haskell.org> References: <047.01134e82983fb263026aa29a14aa8897@haskell.org> Message-ID: <062.e7405cf9b1aab1a82cf35932f222a8c6@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: ghci Operating System: Unknown/Multiple | newcomer Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by javran): Newcomer here. I'm interested in this issue. Not sure about the difficulty, so I'll just give some of my thoughts and see if it works out. Currently `:info` isn't doing a good job parsing its arguments, it simply uses `words` to separate arguments so that for `:info (Route App)`, what will `:info` really see is two separated arguments: `(Route` and `App)`. I think the first step is to have some better handling on `:info`, maybe allowing it to accept a list of either names (as before) or type applications (use parentheses to disambiguate it from names). And then we can probably leverage some type checking facilities to help filtering out instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 22:36:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 22:36:25 -0000 Subject: [GHC] #10224: Partial type signatures generate typed hole warnings Message-ID: <045.c9ae412f65588bd6476cb40ffda876e8@haskell.org> #10224: Partial type signatures generate typed hole warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHCi generates typed hole warnings in type signatures even when PartialTypeSignatures is enabled: {{{ > :set -XPartialTypeSignatures > :t (==) :: Char -> _ :1:17: Warning: Found hole ?_? with type: Char -> Bool In an expression type signature: Char -> _ In the expression: (==) :: Char -> _ (==) :: Char -> _ :: Char -> Char -> Bool > :set -XNoPartialTypeSignatures > :t (==) :: Char -> _ :1:17: Found hole ?_? with type: Char -> Bool To use the inferred type, enable PartialTypeSignatures In an expression type signature: Char -> _ In the expression: (==) :: Char -> _ }}} Similarly, GHC 7.10.1, when given the following source, {{{ {-# LANGUAGE PartialTypeSignatures #-} f = (==) :: Char -> _ main = return () }}} mentions that it "found a hole". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 22:51:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 22:51:17 -0000 Subject: [GHC] #10224: Partial type signatures generate typed hole warnings In-Reply-To: <045.c9ae412f65588bd6476cb40ffda876e8@haskell.org> References: <045.c9ae412f65588bd6476cb40ffda876e8@haskell.org> Message-ID: <060.fd204e699943db90c1a90686e32e47e1@haskell.org> #10224: Partial type signatures generate typed hole warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): I think this is the expected behaviour. From the user guide: > By default, the type-checker will report an error message for each hole in a partial type signature, informing the programmer of the inferred type. When the -XPartialTypeSignatures flag is enabled, the type-checker will accept the inferred type for each hole, generating warnings instead of errors. Additionally, these warnings can be silenced with the -fno- warn-partial-type-signatures flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 23:52:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 23:52:20 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.bd75063b37b7aca0a2057e5c01d9c282@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: 5144 | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dmcclean): So sorry guys. min-ghc made some changes to my path that didn't survive a reboot. So I was trying to use this feature for the first time, but at the same time I was unwittingly using 7.8.3 thinking it was 7.10.1. I'll endeavor to be more careful in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 31 23:57:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Mar 2015 23:57:46 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.11248586dbde7f49e27a7f64095c78b9@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): {{{ % ghc -v Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version 7.6.3 Using binary package database: /Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/package.conf.d/package.cache Using binary package database: /Users/yongqli/.ghc/x86_64-darwin-7.10.1/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67 wired-in package base mapped to base-4.8.0.0-9015e10d2b2b0f71f570c3f2bbe09c8a wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-7dd4b8bf14d5c74339cc9bf2cb38ffa4 wired-in package ghc mapped to ghc-7.10.1-c4bfbbb7949f2ae4e8f34b616f56df3b wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: no input files Usage: For basic information, try the `--help' option. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler