From ghc-devs at haskell.org Sun Feb 1 02:09:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 02:09:20 -0000 Subject: [GHC] #10055: Offer PolyKinded instances Data.Fixed.HasResolution Message-ID: <045.258d0e05b323cc5274b998635fcbd7f4@haskell.org> #10055: Offer PolyKinded instances Data.Fixed.HasResolution -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature | Status: new request | Milestone: Priority: low | 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: | -------------------------------------+------------------------------------- Now that we have `DataKinds` and `PolyKinds`, how about offering an instance of `Data.Fixed.HasResolution` for type level natural numbers. For example {{{#!hs instance KnownNat n => HasResolution (n :: Nat) where resolution proxy = 10 ^ natVal proxy }}} or even {{{#!hs instance KnownNat n => HasResolution (n :: Nat) where resolution = natVal }}} This will make it very easy to create fixed-point types on the fly. The following extensions are required for that to work: `DataKinds`, `PolyKinds`, `FlexibleInstances`, and `UndecidableInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 02:17:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 02:17:53 -0000 Subject: [GHC] #10055: Offer PolyKinded instances for Data.Fixed.HasResolution (was: Offer PolyKinded instances Data.Fixed.HasResolution) In-Reply-To: <045.258d0e05b323cc5274b998635fcbd7f4@haskell.org> References: <045.258d0e05b323cc5274b998635fcbd7f4@haskell.org> Message-ID: <060.a190cd1aaa1896d75dc5ef7e782c77f4@haskell.org> #10055: Offer PolyKinded instances for Data.Fixed.HasResolution -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: new Priority: low | 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: -------------------------------------+------------------------------------- Description changed by redneb: Old description: > Now that we have `DataKinds` and `PolyKinds`, how about offering an > instance of `Data.Fixed.HasResolution` for type level natural numbers. > For example > > {{{#!hs > instance KnownNat n => HasResolution (n :: Nat) where > resolution proxy = 10 ^ natVal proxy > }}} > > or even > > {{{#!hs > instance KnownNat n => HasResolution (n :: Nat) where > resolution = natVal > }}} > > This will make it very easy to create fixed-point types on the fly. The > following extensions are required for that to work: `DataKinds`, > `PolyKinds`, `FlexibleInstances`, and `UndecidableInstances`. New description: Now that we have `DataKinds` and `PolyKinds`, how about offering an instance of `Data.Fixed.HasResolution` for type level natural numbers. For example {{{#!hs instance KnownNat n => HasResolution (n :: Nat) where resolution proxy = 10 ^ natVal proxy }}} or even {{{#!hs instance KnownNat n => HasResolution (n :: Nat) where resolution = natVal }}} This will make it very easy to create fixed-point types on the fly. For example, it would be possible to say `0.3 :: Fixed 17`. The following extensions are required for that to work: `DataKinds`, `PolyKinds`, `FlexibleInstances`, and `UndecidableInstances`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 08:07:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 08:07:19 -0000 Subject: [GHC] #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.c9e412b2d0effb860864c3e4b6d02596@haskell.org> #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+-------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+-------------------------------- Comment (by juhpetersen): split fails too But alex and HUnit are okay for example. I am not seeing a pattern yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 10:40:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 10:40:18 -0000 Subject: [GHC] #9930: By default, a source code without extension would get overwritten by executable on *nix In-Reply-To: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> References: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> Message-ID: <064.bfe2f5b1dffd3b3c379d49d5e6bb104f@haskell.org> #9930: By default, a source code without extension would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Rufflewind): * owner: => Rufflewind -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 14:39:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 14:39:53 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ Message-ID: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | 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: | -------------------------------------+------------------------------------- The following compiles as expected: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family Foo a b f :: (Foo a b ~ Int) => a -> b -> b f = error "" }}} but this fails: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family a \\ b f :: (a \\ b ~ Int) => a -> b -> b f = error "" }}} with the error > "The second argument of `(\\)` should have kind `*`, but `b ~ Int` has kind `Constraint`." Thus the first example is being parsed as `(Foo a b) ~ Int`, while the second is parsed as `a \\ (b ~ Int)`. I believe the second example should compile, i.e. `(\\)` and `Foo` should have the same precedence, both of which are higher than `(~)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 15:05:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 15:05:21 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used In-Reply-To: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> References: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> Message-ID: <060.1c0a24ab793d2634d230c4b10dd72dc0@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | AndreasVoellmy Priority: highest | Status: new Component: Runtime System | Milestone: 7.10.1 Resolution: | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9423 | Blocking: | Differential Revisions: Phab:D641 -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * differential: => Phab:D641 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 15:07:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 15:07:45 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used In-Reply-To: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> References: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> Message-ID: <060.25ce8e5ecc9622a83c64a87377b950c5@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | AndreasVoellmy Priority: highest | Status: new Component: Runtime System | Milestone: 7.10.1 Resolution: | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9423 | Blocking: | Differential Revisions: Phab:D641 -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): In the threaded RTS, a signal is delivered from the RTS to Haskell user code by writing to file that one of the IO managers watches (via an instance of GHC.Event.Control.Control). When the IO manager receives the signal, it calls GHC.Conc.Signal.runHandlers to invoke Haskell signal handler. In the move from a single IO manager to one IO manager per capability, the behavior was (wrongly) extended so that a signal is delivered to every event manager (see Trac #9423), each of which invoke Haskell signal handlers, leading to multiple invocations of Haskell signal handlers for a single signal. This change fixes this problem by having the RTS (in generic_handler()) notify only the Control instance used by the TimerManager, rather than all the per-capability IO managers. This has no impact on #9423; i.e. the fix here does not re-introduce the issue identified in #9423. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 17:14:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 17:14:23 -0000 Subject: [GHC] #9930: By default, a source code without extension would get overwritten by executable on *nix In-Reply-To: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> References: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> Message-ID: <064.eb04deb6b322ea17187694da2ac00de0@haskell.org> #9930: By default, a source code without extension would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I would suggest that `-o` be required when the source filename does not have the expected file extension for its language (as specified by `-x`). I'd greatly prefer that to GHC trying to guess whether the user really meant to do what they asked GHC to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 17:17:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 17:17:01 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.851ea09a36bb5c4d86dacd1837b6ce44@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: | -------------------------------------+------------------------------------- Comment (by htebalaka): I was tempted to say precedence rules are the same on the type level. Prefix `Foo` should have higher precedence then any infix expression, and I ''thought'' that infix type operators took the same precedence as their value level versions, though when I tried to construct a quick example to illustrate in GHCi I didn't get that behaviour: {{{ type family a + b type instance a + b = a type family a * b type instance a * b = b :kind! Int + Bool * Char Int + Bool * Char :: * = Char :kind! Int + (Bool * Char) Int + (Bool * Char) :: * = Int }}} :/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 17:30:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 17:30:35 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.56f0b492f2dda1f3c33e74a9affc2c6d@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: | -------------------------------------+------------------------------------- Comment (by crockeea): Replying to [comment:1 htebalaka]: > I ''thought'' that infix type operators took the same precedence as their value level versions I'm not sure what you mean by "value level versions". Surely you wouldn't expect the precedence of your type family `(+) :: * -> * -> *` be related in any way to the function `(+) :: (Num a) :: a -> a -> a`. If I set up two type families {{{!#hs type family Foo a b type family a \\ b infixr 9 \\ }}} we can ask GHCi > `:kind 'Int \\ Int 'Foo' Int` (can't figure out how to put backticks on Foo here) and it will complain that I can't mix an `infixr 9 \\` with `infixl 9 'Foo`, so this indicates that the infix version of `Foo` has the same precedence as the prefix version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 17:44:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 17:44:35 -0000 Subject: [GHC] #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) In-Reply-To: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> References: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> Message-ID: <061.39f6250d61a180119ea17c0fabb30c09@haskell.org> #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) ----------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Changes (by kgardas): * status: new => patch Comment: Fixed in Phab:D640 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 18:29:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 18:29:07 -0000 Subject: [GHC] #10057: Ghc panic with syntax error in data declaration. Message-ID: <042.26ca926a1a6c29c1134c28acf9c7f0f8@haskell.org> #10057: Ghc panic with syntax error in data declaration. -------------------------------------+------------------------------------- Reporter: jfs | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given a spurious "type" after an empty data declaration member list causes my GHC (Debian) to crash. -- test file -- module Test where data X = X {} X -- end test file -- $ ghc Test [1 of 1] Compiling Test ( Test.hs, Test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tc_hs_type: record 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 Feb 1 18:55:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 18:55:25 -0000 Subject: [GHC] #10058: Panic: Loading temp shared object failed Message-ID: <047.df96ee90c5cc42a1abdc47b2157e041f@haskell.org> #10058: Panic: Loading temp shared object failed -----------------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- I ran into a panic when updating `singletons` for 7.10. I'm clueless as to what's going on here, so sorry for not minimizing the test case. A little testing has me convinced it's Template Haskell in some way. To reproduce: {{{ > git clone http://github.com/goldfirere/singletons.git > cd singletons > git checkout ghc-loading-panic-test-case > cabal update > cabal install --only-dependencies > cabal configure > cabal build > cat dist/build/autogen/cabal_macros.h # copy the value for CURRENT_PACKAGE_KEY from the end of cabal_macros.h > cd tests/compile-and-dump > ghc -c -this-package-key -i../../dist/build -XTemplateHaskell Singletons/Maybe.hs }}} You will see something like {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150123 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib, 5): Symbol not found: _mtlzuJNaGzzEkFfL43R3LZZNRlPRm_ControlziMonadziReaderziClass_DZCMonadReader_con_info Referenced from: /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib Expected in: flat namespace in /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've observed this on a Mac, but Travis has the same problem, so it's not strictly Mac-specific. You can see representative Travis output [https ://travis-ci.org/goldfirere/singletons/jobs/49103793 here]. Why am I doing such a crazy thing? It's part of the `singletons` test suite, where it's important to test the output of a run of ghc with `-ddump-splices`. Getting the test cases to compile against the built-but- not-yet-installed `singletons` object files should work with `-this- package-key`. I'm sure there's a better way to structure a testsuite, but this general technique works (with `-package-name` instead of `-this- package-key`) with 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 20:36:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 20:36:07 -0000 Subject: [GHC] #10057: Ghc panic with syntax error in data declaration. In-Reply-To: <042.26ca926a1a6c29c1134c28acf9c7f0f8@haskell.org> References: <042.26ca926a1a6c29c1134c28acf9c7f0f8@haskell.org> Message-ID: <057.2f75cd81c91966a5b2772f20f931534a@haskell.org> #10057: Ghc panic with syntax error in data declaration. -------------------------------------+------------------------------------- Reporter: jfs | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: Thanks for the report, but this is already fixed in 7.8: {{{ rwbarton at morphism:/tmp$ ghc Test [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:2:12: Record syntax is illegal here: {} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 20:43:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 20:43:02 -0000 Subject: [GHC] #10054: Misleading error message from unsaturated type family application In-Reply-To: <046.3310f47d666fed735a640a4960a77ce9@haskell.org> References: <046.3310f47d666fed735a640a4960a77ce9@haskell.org> Message-ID: <061.325d50143bdb754a8fbbda74005fe459@haskell.org> #10054: Misleading error message from unsaturated type family application -------------------------------------+------------------------------------- Reporter: sherman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: type Resolution: fixed | families, constraint kinds Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: Thanks for the report. As you correctly diagnosed, the program is invalid due to the undersaturated type family application in `Foo (Ap Show) a`. The fact that GHC does not report this error (and subsequently gets confused) was a regression introduced somewhere in the 7.8 line, but was fixed in 7.8.4. {{{ rwbarton at morphism:/tmp$ ghc-7.8.1 Test [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:12:9: Type synonym ?Ap? should have 2 arguments, but has been given 1 In the type signature for ?test?: test :: Ap Show a => Foo (Ap Show) a rwbarton at morphism:/tmp$ ghc-7.8.3 Test [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:13:8: Could not deduce (Ap Show a) arising from a use of ?MkFoo? from the context (Ap Show a) bound by the type signature for test :: (Ap Show a) => Foo (Ap Show) a at Test.hs:12:9-36 Relevant bindings include test :: Foo (Ap Show) a (bound at Test.hs:13:1) In the expression: MkFoo In an equation for ?test?: test = MkFoo rwbarton at morphism:/tmp$ ghc-7.8.4 Test [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:12:9: Type synonym ?Ap? should have 2 arguments, but has been given 1 In the type signature for ?test?: test :: Ap Show a => Foo (Ap Show) a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 20:53:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 20:53:01 -0000 Subject: [GHC] #9959: removeDirectoryRecursive should not follow symlinks In-Reply-To: <045.bc668a211256e76b58f6ce62e4042a84@haskell.org> References: <045.bc668a211256e76b58f6ce62e4042a84@haskell.org> Message-ID: <060.a70d3a53e0ea2e9761300119fe8880e9@haskell.org> #9959: removeDirectoryRecursive should not follow symlinks -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: Component: | Version: 7.11 libraries/directory | 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 rwbarton): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 20:59:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 20:59:52 -0000 Subject: [GHC] #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.ab855e86a6d8c5b2ecf0d0039184f3c8@haskell.org> #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I assume you have `-fobject-code` set in your `.ghci`? Anything else relevant? And I assume that `rsa.hs` doesn't do anything unusual (e.g. import GHCi modules)? I can't reproduce it here, but I'm on Linux, so it may be a Mac-only problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 21:02:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 21:02:30 -0000 Subject: [GHC] #7152: Add flag to configure that skips overwriting of symlinks on install In-Reply-To: <044.af90b81c38ba7c31604bedf0b5844194@haskell.org> References: <044.af90b81c38ba7c31604bedf0b5844194@haskell.org> Message-ID: <059.cce78270bcc8dc1ad55a216f156101ac@haskell.org> #7152: Add flag to configure that skips overwriting of symlinks on install -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | thoughtpolice Priority: normal | Status: new Component: Build System | Milestone: 7.12.1 Resolution: | Version: 7.4.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: rwbarton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 21:08:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 21:08:26 -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.50c460d3f2affc37d9aa5a73fc95b66f@haskell.org> #9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: infoneeded 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: #9605 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Yuras): * status: new => infoneeded * related: => #9605 Comment: Thank you for the test case. That is what I get with HEAD: {{{#!haskell test.hs:22:17: Couldn't match type ?Maybe a0? with ?Either String Int? Expected type: Either a1 [Char] -> Either String Int Actual type: Either a1 [Char] -> Maybe a0 The function ?preview? is applied to two arguments, its type is ?Getting (Data.Monoid.First a0) s0 a0 -> m0 (Maybe a0)?, it is specialized to ?Getting (Data.Monoid.First a0) s0 a0 -> Either a1 [Char] -> Maybe a0? In the second argument of ?($)?, namely ?(preview _Left (Right "abc") :: Either String Int)? In the expression: print $ (preview _Left (Right "abc") :: Either String Int) }}} That looks right for me, so I'd say the issue is a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 21:17:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 21:17:55 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.bfd901480fb7cc3dd7178b763684a730@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * type: bug => feature request Comment: Replying to [comment:5 simonpj]: > The Right Thing is, I guess, when given a `.o` file on the command line, to read its interface file, to find what packages it needs, and include those in any link step. A `.o` file on the command line could have come from anywhere, though; it might have been produced by compiling a C file and not have an associated interface file at all. We could record dependency information in the `.o` file in a special section, but that's a bit difficult and nonportable, and doing it just for this purpose seems a bit overkill. I believe GHC is behaving as expected here, and its behavior seems fine to me, so I turned this into a feature request ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 21:28:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 21:28:11 -0000 Subject: [GHC] #10051: panic - the 'impossible' happened In-Reply-To: <046.81c18ed44b1067fab64df95400149350@haskell.org> References: <046.81c18ed44b1067fab64df95400149350@haskell.org> Message-ID: <061.b8a1dd5e51c2d9071c86d3e239b28070@haskell.org> #10051: panic - the 'impossible' happened ---------------------------------+----------------------------------------- Reporter: jpw1991 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #9907 | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by rwbarton): * related: => #7103, #9907 Comment: Or #9907. I don't know enough about Windows to be sure whether these are duplicates, but they all look related at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 21:29:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 21:29:01 -0000 Subject: [GHC] #7103: Compiler panic, when loading wxc in GHCi In-Reply-To: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> References: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> Message-ID: <062.c8e6254e08391cc9e6c7082b4f193134@haskell.org> #7103: Compiler panic, when loading wxc in GHCi -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: 3658 | Test Case: Related Tickets: #9907, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #9907, #10051 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 21:29:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 21:29:14 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.0ec3b7a18113a6637a94678eea675589@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHCi crash | (amd64) Blocked By: | Test Case: Related Tickets: #7103, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #7103, #10051 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 21:52:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 21:52:32 -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.b851ad306db17a9f063bfeb4ef51b563@haskell.org> #10058: Panic: Loading temp shared object failed ---------------------------------+----------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by goldfire): This also happens for testing my `units` library. The testsuite there doesn't do anything particularly strange. However, I can't reproduce locally; only on Travis. See [https://travis- ci.org/goldfirere/units/jobs/49117232 this log]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 22:35:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 22:35:59 -0000 Subject: [GHC] #9930: By default, a source code without extension would get overwritten by executable on *nix In-Reply-To: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> References: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> Message-ID: <064.3597f170642f79a15d54d6ef44da1c0e@haskell.org> #9930: By default, a source code without extension would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Rufflewind): Replying to [comment:3 rwbarton]: > I would suggest that `-o` be required when the source filename does not have the expected file extension for its language (as specified by `-x`). I was thinking of failing with an error only if `-o` is not provided and the input and output filenames would coincide. It's a bit less restrictive than your suggestion and should cover the typical cases where this occurs. What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 22:55:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 22:55:14 -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.4e7fc6836fdf2e5b9bb0ec6502347d3d@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 int-e): SPJ started a discussion about delaying the ghc-7.10 release for this here: https://www.haskell.org/pipermail/ghc-devs/2015-January/008189.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 23:12:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 23:12:06 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.cdcfb6d618303adce182429f0698c5d8@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 crockeea]: > Replying to [comment:1 htebalaka]: > > I ''thought'' that infix type operators took the same precedence as their value level versions > > I'm not sure what you mean by "value level versions". Surely you wouldn't expect the precedence of your type family `(+) :: * -> * -> *` be related in any way to the function `(+) :: (Num a) :: a -> a -> a`. I certainly ''would'' expect the fixity of the type operator `+` to be the same as that of the function `+`, because the parser doesn't know about kinds. It seems the complaint is that `~` has too high a precedence for its purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 23:15:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 23:15:08 -0000 Subject: [GHC] #10059: :i doesn't work for ~ Message-ID: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs Prelude> :set -XTypeOperators Prelude> :i (~) :1:2: parse error on input ?~? Prelude> :k (~) (~) :: k -> k -> Constraint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 23:37:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 23:37:11 -0000 Subject: [GHC] #10060: The Traversable instance for Array looks unlikely to be good Message-ID: <045.a5a4a1a0378588906b6c71666bea7f34@haskell.org> #10060: The Traversable instance for Array looks unlikely to be good -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.11 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, {{{#!hs instance Ix i => Traversable (Array i) where traverse f arr = listArray (bounds arr) `fmap` traverse f (elems arr) }}} Since `traverse` is (inherently) not a good producer for list fusion, this looks suspicious. I think we almost certainly want to walk the array by hand instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 1 23:43:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Feb 2015 23:43:05 -0000 Subject: [GHC] #10060: The Traversable instance for Array looks unlikely to be good In-Reply-To: <045.a5a4a1a0378588906b6c71666bea7f34@haskell.org> References: <045.a5a4a1a0378588906b6c71666bea7f34@haskell.org> Message-ID: <060.ef082e75350e12281dc95b96809d902c@haskell.org> #10060: The Traversable instance for Array looks unlikely to be good -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 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 dfeuer): Er .... actually, the situation is more complex than I thought. Specifically, it sometimes does make sense to do it somewhat like this for something like the `[]` applicative. Ugh. On the other hand, I don't necessarily think traversing an `Array` in `[]` is a terribly sane thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 00:12:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 00:12:43 -0000 Subject: [GHC] #10060: The Traversable instance for Array looks unlikely to be good In-Reply-To: <045.a5a4a1a0378588906b6c71666bea7f34@haskell.org> References: <045.a5a4a1a0378588906b6c71666bea7f34@haskell.org> Message-ID: <060.1340f438f8f53454148e17df609080f7@haskell.org> #10060: The Traversable instance for Array looks unlikely to be good -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: invalid | 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 dfeuer): * status: new => closed * resolution: => invalid Comment: Yeah, this probably just isn't even possible at all. Sorry. There may be some room for improvement, but I'll need to think on it more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 00:54:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 00:54:04 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.85920fbb5d7d2af5c28e1ed7a55ca114@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.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 -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 simonpj]: > Can you offer a reproducible test case, and timing or allocation data? I had one, and then I lost it. I wish I could give you one as a test case and for future analysis. It was something very simple, and the `mapM_` of 4.7 was consistently the same as the version in the linked differential, and both allocated less than the version currently in head. I believe it had to be an arity issue. Call arity wasn't catching it for some reason, so it needed input from the other arity analysis that it wasn't getting. Consider the current definition: {{{#!hs mapM_ f = foldr ((>>) . f) (return ()) }}} Taking apart the argument to `foldr` above gives {{{#!hs mapM_ f = foldr (\m -> (>>) (f m)) (return ()) }}} Now fuse this with `build g`: {{{#!hs mapM_ f (build g) = g (\m -> (>>) (f m)) (return ()) }}} Without knowing what the monad is, `mapM_` doesn't know that `(>>)` has arity 2, and relies on Call Arity analysis of `g`, which I imagine wasn't working in whatever example I was dealing with. What I propose below forces the arity up to 2, and is also significantly easier to read. {{{#!hs {-# INLINE mapM_ #-} mapM_ f = foldr (\m n -> f m >> n) (return ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 01:54:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 01:54:29 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.baee8309d37d99f8bbe4fed45f580388@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: | -------------------------------------+------------------------------------- Comment (by goldfire): Here's what I know about all of this, to the best of my knowledge: - Types do ''not'' "inherit" fixity from terms. The type family `(+) :: * -> * -> *` (or whatever kinds) is completely and totally unrelated to the term-level variable `(+) :: Num a => a -> a -> a`. - There is no way in a fixity declaration to specify what namespace you want the declaration to operate over. So, in (what I consider to be) a terrible hack, a fixity declaration will affect either or both of local term-level and type-level definitions. So, if you have {{{ (//) :: a -> a -> a (//) = ... type family (//) a b infixl 5 // }}} then ''both'' the term `(//)` and the type `(//)` get the given fixity. This isn't a case of one inheriting the fixity from the other or being at all related -- it's just a peculiar meaning given to a fixity declaration. - While the parser doesn't know what type a term has, it ''does'' know whether you're writing a term, a type, or a kind. So it can behave differently in each of these cases -- they're all syntactically distinct in Haskell source. - Traditional fixity declarations don't affect the parser. And, upon some thought, we realize they can't: a fixity declaration can't be acted upon until after (or in) the renamer, when we know where a symbol is declared. - `(~)` is parsed separately from the normal infix operators. Recall that `TypeOperators` used to require type-level operators to begin with `:`. `(~)` does not, and so it must be special. Now that `TypeOperators` has been changed, there actually doesn't seem to be a good reason to keep `(~)` special. It's declared (in `ghc-prim:GHC.Types`). It has magic in the solver, but there needs to be no magic dealing with naming or parsing. However, simply removing the magic causes several minor conundrums: - Do we require `TypeOperators` when `~` appears in source code? Currently, we don't. - Do we require `TypeFamilies` or `GADTs` when `~` appears in source code? Currently, we do, but if we drop the magic, this decision is suspect, especially if `~` isn't ever really acted on in the module (because it appears only on the RHS of a type synonym, say). - Should `(~)` be imported as part of the Prelude? If no, then a lot of code breaks. If yes, that implies that hiding the Prelude also hides `(~)`, breaking less code, but still breaking code. These issues are surmountable, perhaps, but when I looked at making `~` non-magical, I discovered both that it's technically quite straightforward and socially rather annoying for little benefit. I suppose there's a middle road where it's non-magical in the parser but magical in the renamer. When I realized how tangled this all was, I gave up, as I was just doing some cleaning. Now that bugs are actually appearing, there might be more incentive to come up with a consistent response. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 01:57:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 01:57:21 -0000 Subject: [GHC] #10059: :i doesn't work for ~ In-Reply-To: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> References: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> Message-ID: <060.2e4e1ebd7be0d52e95f9772395959022@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10056 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #10056 Comment: See comment:4:ticket:10056. The last point there explains, essentially, why this is happening. Both #10056 and this ticket have the same resolution. I'm not quite labeling this a duplicate of #10056, because this is worth a separate regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 01:57:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 01:57:52 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.7e099d8e3eb06805b19746bdecc03bcf@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 | -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #10059 Comment: See also #10059 for another place where the magic behind `(~)` causes weird behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 03:23:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 03:23:24 -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.b61bd17d66e38225e10e2b29ef4e1829@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 goldfire): Take a look at [wiki:Typeable#Medium-termsolution this wiki page]. It includes a solution that we think can be done in time for 7.10 if there is a delay. What's nice about this one is that it should break no existing code. Depending on design decisions, we would probably warn about `Typeable` instances (which would no longer be necessary), but nothing should outright break. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 04:47:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 04:47:30 -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.d740ec2df999a9eb788b15f5f607227c@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 oerjan): Replying to [comment:42 goldfire]: > What's nice about this one is that it should break no existing code. It may be too weird to count as "existing code", but can it handle this? {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DeriveDataTypeable #-} import Data.Typeable newtype C a b = C () deriving Typeable step :: Proxy (a :: k) -> Proxy (C a :: k -> *) step Proxy = Proxy nest :: Typeable a => Int -> Proxy a -> TypeRep nest 0 x = typeRep x nest n x = nest (n-1) (step x) main = print $ nest 10 (Proxy :: Proxy ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 08:08:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 08:08:43 -0000 Subject: [GHC] #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.90709aaa556509e4a88d357b612daaa6@haskell.org> #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+-------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+-------------------------------- Comment (by juhpetersen): OK: shake, happy fails: zip-archive, texmath But, maybe the problem is more general (from darcs package build): {{{ : ./dist/build/darcs/darcs --preprocess-manual darcs.tex --html >doc/manual/darcs.texdarcs: internal error: evacuate(static): strange closure type 65144 (GHC version 7.8.4 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 09:01:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 09:01:13 -0000 Subject: [GHC] #10048: {-# UNPACK #-} support for size-indexed types In-Reply-To: <045.3007e0354ab047007432d2f1d345858f@haskell.org> References: <045.3007e0354ab047007432d2f1d345858f@haskell.org> Message-ID: <060.374bd358f47ae340e2482952c8b7ecf3@haskell.org> #10048: {-# UNPACK #-} support for size-indexed types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): A difficulty is that in GHC today, each data constructor (such as `Cons` above) has a single, fixed memory layout. So if we have {{{ data T = MkT Bool {-# UNPACK !(Int, Int) #-} }}} we can decide to lay out `MkT` with a `Bool` field and two `Int` fields. But if we don't know `l`, we don't know how `HList l` is represented, so we can't do that. It's not just an implementation matter. Suppose at an allocation site we were allocating a `Cons` whose first arg was `'[Int,Bool]`. Then you could imagine whizzing up a specialised `Cons` constructor. But then `hlength` above would have to be able to consume that constructor! I don't know any way to do this without monomorphising the code. Which is often, ''but not always'' possible, so you'd also need an escape hatch for the impossible case -- and it's not obvious how to build the hatch. PhD thesis anyone? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 09:12:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 09:12:24 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.f151cd5586e3b6966bec8f79faa30890@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | profiling/should_run/scc004 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * cc: scpmw (added) * status: infoneeded => new Comment: `-fprof-auto` is needed to get the `main` SCC too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 09:22:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 09:22:07 -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.c169b56b25fcdc6a53bd172d5d0e4829@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: new Priority: normal | 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * cc: simonmar (added) * component: Compiler => Runtime System * failure: None/Unknown => Runtime crash * architecture: x86_64 (amd64) => Unknown/Multiple * owner: => trommler * os: MacOS X => Unknown/Multiple Comment: Replying to [comment:1 goldfire]: > This also happens for testing my `units` library. The testsuite there doesn't do anything particularly strange. However, I can't reproduce locally; only on Travis. See [https://travis- ci.org/goldfirere/units/jobs/49117232 this log]. Travis is Linux, isn't it? I'll have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 09:27:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 09:27:26 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.1dd9282fd72e697859ca2ac2f5ee3f8e@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by simonpj): I don't object to putting this fix in 7.10. I've looked at the patch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 10:13:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 10:13:19 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.e49e29ab3eacb90e518b0e9b37f8201a@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by ezyang): I decided to solve this problem by assuming template var quantifiers are in the same order as the list of template variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 11:21:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 11:21:43 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.af420e1c5171f4dc1f8f54a61c8c7a75@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.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 -------------------------------------+------------------------------------- Comment (by simonpj): I still don't follow from comment:2 where the performance loss you describe is coming from, nor why inlining `mapM` will help. If you do have a clear idea, can you ''construct'' an example? Switch off Call Arity if you like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 12:28:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 12:28:06 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.313262b37cdfb3c5f6e54710e57e64ec@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by simonpj): Edward, let's Skype about this. I don't understand the ramifications yet. Ping me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 14:26:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 14:26:30 -0000 Subject: [GHC] #10027: Importing constructor of associated data type fails In-Reply-To: <048.077c953371a360576ad660349e5d3261@haskell.org> References: <048.077c953371a360576ad660349e5d3261@haskell.org> Message-ID: <063.9a919fc862b6850118e3ec1dab95a264@haskell.org> #10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | constructor import associated data Type of failure: None/Unknown | type Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Putting comment:6 and comment:7 together, maybe {{{ pattern T( C1, C2, C3 ) }}} exports only data constructors `C1`, `C2`, `C3`, but not `T`. And then {{{ pattern T(..) }}} would export all the constructors, but not `T`. Another alternative {{{ pattern C.. }}} exports all `C` and all the other peer constructor from `C`'s data type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 16:05:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 16:05:07 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used In-Reply-To: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> References: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> Message-ID: <060.0efd7534cda9ac899ee18d2fa22e6554@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | AndreasVoellmy Priority: highest | Status: new Component: Runtime System | Milestone: 7.10.1 Resolution: | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9423 | Blocking: | Differential Revisions: Phab:D641 -------------------------------------+------------------------------------- Comment (by Andreas Voellmy ): In [changeset:"92c93544939199f6ef758e1658149a971d4437c9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="92c93544939199f6ef758e1658149a971d4437c9" Fix #10017 Summary: In the threaded RTS, a signal is delivered from the RTS to Haskell user code by writing to file that one of the IO managers watches (via an instance of GHC.Event.Control.Control). When the IO manager receives the signal, it calls GHC.Conc.Signal.runHandlers to invoke Haskell signal handler. In the move from a single IO manager to one IO manager per capability, the behavior was (wrongly) extended so that a signal is delivered to every event manager (see #9423), each of which invoke Haskell signal handlers, leading to multiple invocations of Haskell signal handlers for a single signal. This change fixes this problem by having the RTS (in generic_handler()) notify only the Control instance used by the TimerManager, rather than all the per-capability IO managers. Reviewers: austin, hvr, simonmar, Mikolaj Reviewed By: simonmar, Mikolaj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D641 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 16:05:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 16:05:07 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.aff892cae674dcb926128991917527cc@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime System | 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: 9284 | Differential Revisions: Phab:D129 -------------------------------------+------------------------------------- Comment (by Andreas Voellmy ): In [changeset:"92c93544939199f6ef758e1658149a971d4437c9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="92c93544939199f6ef758e1658149a971d4437c9" Fix #10017 Summary: In the threaded RTS, a signal is delivered from the RTS to Haskell user code by writing to file that one of the IO managers watches (via an instance of GHC.Event.Control.Control). When the IO manager receives the signal, it calls GHC.Conc.Signal.runHandlers to invoke Haskell signal handler. In the move from a single IO manager to one IO manager per capability, the behavior was (wrongly) extended so that a signal is delivered to every event manager (see #9423), each of which invoke Haskell signal handlers, leading to multiple invocations of Haskell signal handlers for a single signal. This change fixes this problem by having the RTS (in generic_handler()) notify only the Control instance used by the TimerManager, rather than all the per-capability IO managers. Reviewers: austin, hvr, simonmar, Mikolaj Reviewed By: simonmar, Mikolaj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D641 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 16:08:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 16:08:00 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used In-Reply-To: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> References: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> Message-ID: <060.46ae78d2128856260d3ed2e204e51855@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | AndreasVoellmy Priority: highest | Status: merge Component: Runtime System | Milestone: 7.10.1 Resolution: | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9423 | Blocking: | Differential Revisions: Phab:D641 -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 17:59:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 17:59:16 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used In-Reply-To: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> References: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> Message-ID: <060.5e0c0866795948d71164860acec1b261@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | AndreasVoellmy Priority: highest | Status: closed Component: Runtime System | Milestone: 7.10.1 Resolution: fixed | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9423 | Blocking: | Differential Revisions: Phab:D641 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Boom, headshot. Merged to `ghc-7.10` via ddd95c0b575da33447c078a8791d3c4f2edec9b7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 21:45:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 21:45:48 -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.ce7da3e9d9a6647a31fbf48758cced19@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-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * failure: None/Unknown => Documentation bug * resolution: => fixed Comment: Closed via cd0bbc5421f16a599a40468cd45161c7ed798696. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 21:46:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 21:46:07 -0000 Subject: [GHC] #9937: add updated prefetch API mention to the 7.10 release notes In-Reply-To: <045.aae52c0ceb53669bf5d53bc76be3d55f@haskell.org> References: <045.aae52c0ceb53669bf5d53bc76be3d55f@haskell.org> Message-ID: <060.41b37439575680b3b02be0e3764f6b8c@haskell.org> #9937: add updated prefetch API mention to the 7.10 release notes -------------------------------------+------------------------------------- Reporter: carter | 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: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Closed via aafc41589a38e71d8f9f84c603f19d3e22553268. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 22:01:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 22:01:26 -0000 Subject: [GHC] #10061: Remove fun_infix from Funbind, as it is now in Match Message-ID: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> #10061: Remove fun_infix from Funbind, as it is now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.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: #9988 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- One of the changes Phab:D538 introduced is to add m_fun_id_infix to Match {{{#!hs data Match id body = Match { m_fun_id_infix :: (Maybe (Located id,Bool)), -- fun_id and fun_infix for functions with multiple equations -- only present for a RdrName. See note [fun_id in Match] m_pats :: [LPat id], -- The patterns m_type :: (Maybe (LHsType id)), -- A type signature for the result of the match -- Nothing after typechecking m_grhss :: (GRHSs id body) } deriving (Typeable) }}} This was done to track the individual locations and fixity of the fun_id for each of the defining equations for a function when there are more than one. For example, the function (&&&) is defined with some prefix and some infix equations below. {{{#!hs (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys }}} This means that the fun_infix is now superfluous in the FunBind. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after. This ticket captures that task, which includes processing these fields through the renamer and beyond. Ticket #9988 introduced these fields into Match through renaming, this ticket it to continue through type checking and then remove it from FunBind completely. The split happened so that #9988 could land in 7.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 22:01:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 22:01:39 -0000 Subject: [GHC] #10061: Remove fun_infix from Funbind, as it is now in Match In-Reply-To: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> References: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> Message-ID: <059.1093d62a867dc2b8f79eb56eacbee19c@haskell.org> #10061: Remove fun_infix from Funbind, as it is now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | 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: #9988 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * owner: => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 22:02:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 22:02:49 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.9b7732d9f238ee82deefc59305ee29b6@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | 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 alanz): * priority: normal => highest * milestone: 7.12.1 => 7.10.1 Comment: Updating milestone and priority to make 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 2 22:17:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Feb 2015 22:17: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.fcc8d49d6dcac10120a2828029d02cc4@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-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by asr): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 00:32:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 00:32:40 -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.1339c84e61ea1de255bb2cc6bb3efb4b@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: -------------------------------------+------------------------------------- Changes (by liyang): * cc: liyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 02:01:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 02:01:11 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.06a647a3eff2f57f6e704201dbee2aec@haskell.org> #8732: Global big object heap allocator lock causes contention -------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | 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: -------------------------------------+------------------------------------- Comment (by tibbe): What about the idea of just using malloc? Modern mallocs like TCMalloc are already multithreaded and seem to just deal with all the annoying issues. Gregory Collins said that in Snap they just don't use the "built-in" ByteString construction functions and instead just call malloc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 08:46:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 08:46:58 -0000 Subject: [GHC] #10062: Codegen on sequential FFI calls is not very good Message-ID: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> #10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm writing a library for efficiently building up a byte buffer. The fastest approach I've found is via FFI, with restricted effects like ST. It's over twice as fast as ByteString Builder. Consider this example API usage: https://github.com/chadaustin/buffer- builder/blob/6bd0a39c56f63ab751faf29f9784ac87d52638be/bench/Bench.hs#L46 It compiles into an instruction sequence containing direct, sequenced FFI calls. For example, the last three calls work out to: addq $8,%rsp movq %rbx,%rdi movq 72(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz addq $8,%rsp movq %rbx,%rdi movl $35,%esi subq $8,%rsp movl $0,%eax call bw_append_byte addq $8,%rsp movq %rbx,%rdi movq 64(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz I don't know why rsp is being changed so much. I also can't explain the assignment to eax before the call. (It should also be xorl eax,eax, I would think.) To my reading, the above instruction sequence could be reduced to: movq %rbx,%rdi movq 64(%rsp),%rsi call bw_append_bsz movq %rbx,%rdi movl $35,%esi call bw_append_byte movq %rbx,%rdi movq 56(%rsp),%rsi call bw_append_bsz To reproduce, check out git at github.com:chadaustin/buffer-builder.git at revision 6bd0a39c56f63ab751faf29f9784ac87d52638be cabal configure --enable-benchmarks cabal bench And then look at the ./dist/build/bench/bench-tmp/bench/Bench.dump-asm file. This is specifically on OS X 64-bit with GHC 7.8.3, but I saw similar code generation on GHC 7.6 on Linux 64-bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 09:38:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 09:38:42 -0000 Subject: [GHC] #10062: Codegen on sequential FFI calls is not very good In-Reply-To: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> References: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> Message-ID: <064.8ad47cc3574646bc251dc5b0522bf092@haskell.org> #10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Yuras): > I don't know why rsp is being changed so much. It is necessary because `ccall` calling convention requires alignment that is different from the one used in `ghc`, see [[https://github.com/ghc/ghc/blob/64678e9e8ff0107cac956f0c7b799a1dd317b963/compiler/nativeGen/X86/CodeGen.hs#L2320|here]] for details. Though all this `addq`/`subq` probably can be combined... IIRC we don't have optimization pass for asm (?) > I also can't explain the assignment to eax before the call It is required by calling convention [[https://github.com/ghc/ghc/blob/64678e9e8ff0107cac956f0c7b799a1dd317b963/compiler/nativeGen/X86/CodeGen.hs#L2357|too]]. So, the generated code is pretty reasonable, but there definitely is space for improvements. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 09:39:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 09:39:27 -0000 Subject: [GHC] #10062: Codegen on sequential FFI calls is not very good In-Reply-To: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> References: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> Message-ID: <064.aaac12807fefdd9123256cedd5eb8ac7@haskell.org> #10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by Yuras): * cc: shumovichy@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 10:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 10:00:27 -0000 Subject: [GHC] #10062: Codegen on sequential FFI calls is not very good In-Reply-To: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> References: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> Message-ID: <064.381bd884612854b9a3f3b9b784fb2aee@haskell.org> #10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by chadaustin): Wow! Thanks for the fast response! The ABI constraints make sense. In light of them, then yes, the improvements would be: * Change "movl $0,%eax" to "xorq %rax,%rax" (or maybe "movb $0,%al", though I don't know whether a smaller instruction is more important than breaking the data dependency on rax) * Merge the rsp additions and subtractions between FFI calls * Eliminate the extra move in "movq 72(%rsp),%rax; movq %rax,%rsi" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 11:42:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 11:42:40 -0000 Subject: [GHC] #10062: Codegen on sequential FFI calls is not very good In-Reply-To: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> References: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> Message-ID: <064.916cf5b4c8e1ba750207bae78fee8d64@haskell.org> #10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by svenpanne): A quick remark regarding "xorq %rax,%rax" vs. "movb $0,%al": I would recommend the xorq variant, we had very bad experiences with data dependencies between partially written registers in the v8 JavaScript JIT. Intel CPUs have funny performance characteristics, and these vary vastly between architectures and even releases of the same architecture. :-/ No need to repeat the pain in GHC... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 13:22:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 13:22:19 -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.508f8324861b86493512cf000e350cd6@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 goldfire): Replying to [comment:43 oerjan]: > It may be too weird to count as "existing code", but can it handle this? Let's see. Everything is peachy until the second clause for `nest`. There, we assume `Typeable a` (writing the implicit kind argument in angle brackets) and must produce `Typeable *> (C a)`. I believe a sufficiently smart solver should be able to do this without difficulty. It will have access to fingerprint information for `k`, and should be able to build a fingerprint for `k -> *` from what it has. Good test case, but it seems workable with the proposed fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 16:15:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 16:15:57 -0000 Subject: [GHC] #10062: Codegen on sequential FFI calls is not very good In-Reply-To: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> References: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> Message-ID: <064.c3d70b2f5360c8d202d3fe16884bc47d@haskell.org> #10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): > Change "movl $0,%eax" to "xorq %rax,%rax" (or maybe "movb $0,%al", though I don't know whether a smaller instruction is more important than breaking the data dependency on rax) This one is already implemented in GHC 7.10. (xor %eax,%eax is the Officially Correct instruction to use: it is the smallest instruction to clear a register and it has special processor support to break dependency chains, even though it looks like it doesn't). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 20:55:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 20:55:28 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.a72c2c87d75749a710c5a02b3d4e3160@haskell.org> #8732: Global big object heap allocator lock causes contention -------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | 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: -------------------------------------+------------------------------------- Comment (by simonmar): Malloc is fine for ByteStrings, but we can't use it for heap-resident objects due to the way block descriptors work. Our memory is always MB- aligned, so that we can put the block descriptors at the beginning of the MB. Also the GC has to be able to distinguish heap memory from non-heap memory, and we currently take advantage of the fact that memory is allocated in MB chunks to reduce the granularity that we have to map the address space. The contiguous-heap patch solves this in a different way (that is also incompatible with malloc). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 3 20:59:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Feb 2015 20:59:56 -0000 Subject: [GHC] #10063: State a law for foldMap Message-ID: <045.2d91739a7068920001aea2bab20d88fb@haskell.org> #10063: State a law for foldMap -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: feature | Status: new request | Milestone: 7.12.1 Priority: low | Version: 7.10.1-rc1 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Documentation Keywords: | bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After being prodded by /u/random_crank on reddit, I realized there is a law we can state for `foldMap`: A monoid homomorphism `g` is a function such that {{{#!hs g mempty = mempty g (mappend a b) = mappend (g a) (g b) }}} holds. For any monoid homomorphism `g`: {{{#!hs foldMap (g . f) = g . foldMap f }}} This isn't strictly a free theorem as it relies on the `Monoid` laws, but it is true and has the same general flavor as the equally complicated free theorem for `foldr`. This law is a bit technical, but is a nice tool for equational reasoning, and gives rise to a much nicer `foldMap`-based version of the "banana split" theorem for `foldr`. {{{#!hs foldMap f &&& foldMap g = foldMap (f &&& g) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 01:49:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 01:49:02 -0000 Subject: [GHC] #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.2e32d920d3a09a7094a8dcaf7ddf203c@haskell.org> #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): I can reproduce it with -fobject-code set in .ghci But I can also do it no .ghci and just loading object code I now have a file mainbug.hs that consists of {{{ main = print "hello" }}} I can reproduce it as follows: {{{ ghc -dynamic mainbug.hs [1 of 1] Compiling Main ( mainbug.hs, mainbug.o ) Linking mainbug ... bash-3.2$ ghci GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :load mainbug Ok, modules loaded: Main. Prelude Main> :show modules Main ( mainbug.hs, mainbug.o ) Prelude Main> main Too late for parseStaticFlags: call it before runGhc or runGhcT *** Exception: ExitFailure 1 }}} Loading it interpreted works fine: {{{ rm mainbug.o bash-3.2$ ghci GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :load mainbug [1 of 1] Compiling Main ( mainbug.hs, interpreted ) Ok, modules loaded: Main. *Main> main "hello" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 01:59:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 01:59:08 -0000 Subject: [GHC] #10064: Add support for "foo"## literals to MagicHash Message-ID: <049.cb303598e29d32fcc2ec0d8e38051be4@haskell.org> #10064: Add support for "foo"## literals to MagicHash -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature | Status: new request | Milestone: Priority: normal | 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: | -------------------------------------+------------------------------------- I'm working on a high-performance library for building up buffers of data. Appending ByteStrings works pretty well, but, for bytestring literals, it's faster to avoid the CAF (and it's associated tag check + indirect jump) entirely and append a zero-terminate MagicHash string literal via Addr#. Then I discovered that it's 30% faster if you can avoid the strlen with an explicit length. See this benchmark: https://github.com/chadaustin /buffer- builder/blob/ac662962d6d3c21f206ab8e8121323b9f18677fa/bench/Bench.hs#L42 That API is not very pleasant, of course. :) Thus, here is a feature request: It would be great if "foo"## produced (# Int#, Addr# #), where the Int# is the length of the buffer in bytes. The compiler could enforce that the literal only contains 8-bit values. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 02:33:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 02:33:30 -0000 Subject: [GHC] #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.97f313127e4c853867f2bed103281f62@haskell.org> #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): OK, now I can reproduce your output exactly except for the error itself, so it seems to indeed be a Mac-specific bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 04:33:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 04:33:11 -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.b62cbbd29aec9a79a97ba9e86fcc12b4@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 oerjan): Ah, I had misunderstood what the wiki page said, then. Now this gives me an idea for a expanded test case. If my picture of how such a solver would work is now more correct, then I think by expanding the kinds in my example a bit, we can get a case where the solver would need not just to ''build'' new kind reps, but also to take the kind rep inside its provided `Typeable` instance further apart. And for good measure let's include a data kind as well: {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable newtype C a b = C () step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *) step Proxy = Proxy nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep nest 0 x = typeRep x nest n x = nest (n-1) (step x) main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *)) }}} Assuming you would want to support this kind of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 05:20:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 05:20:43 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.a563510db969d9e18c760fad74da9699@haskell.org> #8266: Dynamic linking on Mac -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by PHO): * cc: PHO (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 07:59:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 07:59:56 -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.8c9ecc57fd0946cde66a4489943ec39b@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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: duncan (added) Comment: I think duncan may have some opinion here... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 09:04:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 09:04:18 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.4db7d8825249ddbd6285b45436af8bfb@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Profiling | 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: #9961 | Differential Revisions: Phab:D616 | Phab:D636 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"daed18c35cda114d8a5303bcb645195e1fd397e3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="daed18c35cda114d8a5303bcb645195e1fd397e3" Fix a profiling bug Summary: We were erroneously discarding SCCs on function-typed variables. These can affect the call stack, so we have to retain them. The bug was introduced during the recent SourceNote refactoring. This is an alternative to the fix proposed in D616. I also added the scc005 test from that diff, which works with this change. While I was here, I also fixed up the other profiling tests, marking a few as expect_broken_for(10037) where the opt/unopt output differs in non-fatal ways. Test Plan: profiling tests Reviewers: scpmw, ezyang, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D636 GHC Trac Issues: #10007 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 09:06:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 09:06:16 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.4cf3d0258daac8acadf1e96bf4b0c962@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Profiling | 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: #9961 | Differential Revisions: Phab:D616 | Phab:D636 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => merge Comment: ...I assume this is to be merged to 7.10? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 09:16:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 09:16:07 -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.d90df200cb5250ffb562ecc791d80d4c@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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Is this the same as #5218? Which needs love. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 09:59:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 09:59:43 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.d564a87496108993d68ee9f696f28aed@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Profiling | 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: #9961 | Differential Revisions: Phab:D616 | Phab:D636 -------------------------------------+------------------------------------- Comment (by scpmw): Well, it's the wrong fix, as far as I'm concerned. Yes, it fixes the erroneous attribution to `lintAnnots`, but only because we change the program's (RTS) cost semantics twice during optimisations, with both instances un-doing each other. This is not guaranteed, see the new test case for `D616`. I also didn't feel it would help the discussion to mention this - but this also doesn't fix rather silly double-annotations on parameters, which (I think) only don't appear because we automatically eliminate repeating cost centres in stacks. If needed, I could produce another test case that demonstrates that. Short version: This is only a band-aid. And as far as those go, I would still prefer `D616`. At least until I have figured out how to *actually* implement `Eval2`, which would fix the whole situation from the RTS end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 10:15:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 10:15:16 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.1c34895aee28d28bba91f759d639cfb8@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: 7.12.1 Resolution: | Version: 7.0.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Runtime | Architecture: performance bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #5877 #10064 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: 5877 => #5877 #10064 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 10:50:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 10:50:45 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.56de201201e5aaedbe4b608113991a17@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | 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: D639 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => D639 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 13:20:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 13:20:29 -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.547dbad89ca1f37de6ea931530c4903a@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 goldfire): Here, we would be given `Typeable <[k] -> *> a` and need to derive `Typeable <[k -> *] -> *> (C <[k] -> *> <[k -> *]> a)`. Yes, that ''would'' require decomposition, indicating that we should store more than just the kind fingerprint. Another very nice test case. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 13:33:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 13:33:28 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.e73b4c7ecb181c29384c29e806f1c9a9@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Profiling | 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: #9961 | Differential Revisions: Phab:D616 | Phab:D636 -------------------------------------+------------------------------------- Comment (by simonmar): I respectfully disagree that is is a band-aid. It is not a complete fix, but it does fix a regression since 7.8, so it should definitely go into 7.10. I'll continue to discuss the larger issue on D616. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 13:34:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 13:34:08 -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.a58283e89f5f76e755e551646c61d67c@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: new 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => highest Comment: Thanks for looking into this. I'm bumping the priority up to highest, because it would be embarrassing to release 7.10.1 with this bug in it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 17:14:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 17:14:03 -0000 Subject: [GHC] #10065: Definition of fix lacks commentary Message-ID: <045.47fbd4fc1d6a2c2a1c9fdee551290b60@haskell.org> #10065: Definition of fix lacks commentary -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.11 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In `Data.Function`, {{{#!hs fix :: (a -> a) -> a fix f = let x = f x in x }}} It is not immediately obvious why it is defined like this, rather than the more natural {{{#!hs fix f = f (fix f) }}} There are very good reasons for this; notably, it allows for the definition of circular data structures. But there should be a comment explaining this, preferably in the Haddocks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 18:01:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 18:01:32 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.372341ba3ab9c78af5001ac79aafedf6@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 dorchard): Hi, Sorry to throw in a late thought, but what about adding a kind of injectives `>->`? e.g.`* >-> *`is the kind of injective type functions (as proved by the compiler, and perhaps as explicitly annotated by the user). This would provide a way to propagate the injectivity information within the type checker, and could also be an alternative (replacement?) for using the functional dependency syntax here (although, I think that syntax makes a lot of sense). I suppose it is not currently possible to specify this for a type family, unless kind signatures on type family names were possible, e.g. {{{ type family (Id :: * >-> *) a where Id a = a }}} but this wouldn't be hard to add I don't think. Note that data family could then be given the injective kind too. This might provide some simplification in the type checker? I don't know for sure though. Just a thought, but thought it worth mentioning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 18:36:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 18:36:08 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.3ab428c0fddeb6a9327aa26403ce46da@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | 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: Phab:D639 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D639 => Phab:D639 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 20:04:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 20:04:12 -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.143bef4d70fbacdf64ba90192c1e82df@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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by chadaustin): Hi! I don't think it's exactly the same as #5218 since I don't specifically need ByteStrings here, just a quick Int#, Addr# pair. But #5218 could definitely be implemented on top of a mechanism that desugars to this (e.g. unpackCStringLen "my literal"##). If you'd like to merge the bugs, that's fine with me, as long as there's a way to get at some machinery to generate string length Int#s at compile time. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 4 21:40:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Feb 2015 21:40:06 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.cc44317bfdb5a9f79d85c65269e71279@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 dfeuer): I don't see the problem with letting injective families call other type families as long as there is no recursion?can't GHC follow all paths to the end when necessary, and use injectivity "lemmas" when possible for efficiency? Or does this end up not being useful/efficient/possible for some reason? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 00:42:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 00:42:47 -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.ab3732bc3c1b2d45bd1a0a419679759f@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 oerjan): I was going to say that this need to do kind decomposition when inferring `Typeable` instances is why this cannot be done just with standalone instances, and you need a solver. In fact the last time I gave up on my [comment:33 attempt] to express this in source code, it was because I realized that the fundamental instance {{{ instance (Typeable a, Typeable b) => Typeable (a b) }}} already needs such decomposition to be written. But today I had an epiphany: This ''can'' be expressed with current types, although with the annoying need to wrap kinds in proxies: {{{ -- Ideally k itself should be the class argument, but that is not yet -- supported. I think this is what makes UndecidableInstances -- necessary for defining instances. Fortunately the instances seem to be -- usable without it. class (KindableParts a, a ~ Proxy) => Kindable (a :: k -> *) where type KindableParts a :: Constraint kindRep :: KindRep a class Kindable (Proxy :: k -> *) => Typeable (a :: k) where typeRep :: proxy a -> TypeRep }}} I wrote up enough of a mock implementation to make the last test case above work with this. The code is a bit long, so I put it [http://oerjan.nvg.org/haskell/TypeableDesign/ on my website]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 05:43:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 05:43:39 -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.064d3e9fe1abe21b188d010a5bf9452f@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 int-e): I'm wondering about the ramifications of this claim from [[Typeable #Medium-termsolution]]: > Although it is impossible to create all necessary Typeable instances for poly-kinded constructors at the definition site (there's an infinite number), it is possible to create Typeable "instances" on demand at use sites. Consider the following function: {{{ f = \(p :: Proxy Proxy) -> typeRep p }}} Because the kind information of the `p` argument is not fully known at the site of definition, I surmise that the corresponding `Kindable` (to use oerjan's nomenclature) constraint gets propagated outward, meaning that at the core language level, `f` gets an extra argument for passing the `Kindable` evidence for the unknown kind argument of the second `Proxy` type constructor. It is my understanding that for the sake of backward compatibility, this argument is implicit and not visible (even as a constraint) in the Haskell-level type. Is that correct? I feel uncomfortable about this; I like to be able to see in the Haskell type of functions what kind of runtime evidence needs to be passed to a function to make it work. The second thing I'm wondering about is what happens when polymorphic kinds are never instantiated at all. Is the following program valid, and if so, what will the kind of the `Proxy` be at runtime? {{{ {-# LANGUAGE PolyKinds, DataKinds #-} import Data.Typeable main :: IO () main = print (typeRep (Proxy :: Proxy Proxy)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 05:57:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 05:57:24 -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.134266491be49332e82444adf65071ba@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 int-e): Replying to [comment:49 int-e]: > {{{ > f = \(p :: Proxy Proxy) -> typeRep p > }}} Note that currently, the function has type `Proxy Proxy -> Typeable`. What will the type be under the proposed medium term solution? If we want full backward compatibility (and I personally don't think we should strive for that for examples like this one) then passing hidden extra evidence is the only way to go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 15:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 15:22:46 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.205bb9d85dd56c81fc534d4bc8cf1911@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): Dominic, do throw in thoughts at any time. My patch will be ready Real Soon Now but after the merge there will be room for further development of this feature. I will not comment on the proposal of having a separate kind for injective type families. I don't have sufficient knowledge of typechecker to judge whether this would make things easier. Perhaps Simon or Richard can offer some insight here. Regarding your proposed new syntax I believe it does not offer anything new compared to the syntax we decided to use (unless I missed something?). These pairs of definitions would be equivalent: {{{#!hs type family Id a = result | result -> a where {...} type family (Id :: * >-> *) a where {...} type family F a b c = d | d -> a b c type family (F :: * >-> * >->) a b c type family G a b c = foo | foo -> a b where type family (G :: * >-> * -> *) a b c }}} Your syntax however does not extend to injectivity where knowing the result and some of the arguments allows to determine some other arguments: {{{#!hs type family Plus a b = (sum :: Nat) | sum a -> b, sum b -> a where type family H a b c = xyz | xyz a -> b c, xyz b -> a c }}} This kind of injectivity is not implemented in my patch but we want to leave the door open for such a possibility in the future. I'm also not sure if I like how your proposed syntax interacts with PolyKinds: it seems that there would be two alternative places to specify kinds. David, what do you mean by injectivity lemmas? At the moment I don't have a solid stance on the subject of calling type families in the RHS of injective type families. When I started this work it seemed to me that this is not possible. Now I have some more experience so I plan to revisit my earlier decisions. Incidentally, now it seems to me that self-recursion might actually be doable. Calling other type families in the RHS still seems very problematic. First of all called families would have to be injective to declare that a type family that calls them is also injective*. This implies that type families would have to be typechecked in dependency order, which sounds lika a non-trivial technical obstacle. Of course this would prevent type families that form cycles (including mutual recursion) from being injective. Another problem is issue of overlap: {{{#!hs type family Foo a = r | r -> a where Foo (Bar a) = X a Foo (Baz a b) = Y a b }}} To determine whether `Foo` is injective or not we must know whether `X a` and `Y a b` can have identical values (well, types not values). Given that `X` and `Y` can also call other type families I don't see a simple way of checking this. Anyway, the ice here seems very thin and I don't feel confident proceeding further with calling type families by injective type families without formal proof. *) This is a simplifying assumption. It is possible to write a type family that is injective despite calling non-injective type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 15:50:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 15:50:10 -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.d0d38870521e91f2ac94a67803b21991@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 goldfire): > {{{ > f = \(p :: Proxy Proxy) -> typeRep p > }}} More fun test cases! Let's see what GHC will do. First, we must insert kind unification variables: {{{ Proxy :: forall (k :: BOX). k -> * typeRep :: forall (k :: BOX) (proxy :: k -> *) (a :: k). Typeable a => proxy a -> TypeRep f = \(p :: Proxy *> (Proxy )) -> typeRep *> *>> > <$dict> p where $dict :: Typeable *> (Proxy ) }}} We find that `k0` isn't affected by any equality constraints, and so it can be generalized over. We can also generalize over the `Typeable` constraint: {{{ f :: forall (k :: BOX). Typeable *> (Proxy ) => Proxy *> (Proxy ) -> TypeRep }}} In surface syntax, this looks like {{{ f :: Typeable (Proxy :: k -> *) => Proxy (Proxy :: k -> *) -> TypeRep }}} Looks fine to me. Am I missing something? I agree that the solver can't decompose the `Proxy ` argument, but that should be OK. Finding `Typeable` instances (or `Kindable` instances) doesn't involve search, so GHC can look for the "`Kindable`" without decomposing first. If the `Kindable` isn't there, no decomposition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 16:14:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 16:14:35 -0000 Subject: [GHC] #9588: Add `MonadPlus {IO, Either e}` and `Alternative (Either e)` instances In-Reply-To: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> References: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> Message-ID: <057.7fbe26857d68ca491fb68de01b254def@haskell.org> #9588: Add `MonadPlus {IO,Either e}` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | 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): * cc: core-libraries-committee@? (added) * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 16:16:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 16:16:38 -0000 Subject: [GHC] #1990: Add 'subsequences' and 'permutations' to Data.List In-Reply-To: <045.c48177dd9f9efccb66b7d13826a2ad45@haskell.org> References: <045.c48177dd9f9efccb66b7d13826a2ad45@haskell.org> Message-ID: <060.e23c190509312187d0f5f258c16b163c@haskell.org> #1990: Add 'subsequences' and 'permutations' to Data.List -------------------------------------+------------------------------------- Reporter: twanvl | Owner: igloo Type: proposal | Status: closed Priority: high | Milestone: 6.10 Component: libraries/base | branch Resolution: fixed | Version: 6.8.1 Operating System: Unknown/Multiple | Keywords: report- Type of failure: None/Unknown | impact Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * failure: => None/Unknown * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 16:20:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 16:20:33 -0000 Subject: [GHC] #9767: Add isSubsequenceOf to Data.List In-Reply-To: <047.a10d1fc86511a46e367bb032e95edccd@haskell.org> References: <047.a10d1fc86511a46e367bb032e95edccd@haskell.org> Message-ID: <062.9da21048f41c24232cbe9fedc1e973f7@haskell.org> #9767: Add isSubsequenceOf to Data.List -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 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 Thu Feb 5 16:24:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 16:24:07 -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.650d583fb25e20a3df73eb3f9984109e@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 int-e): > {{{ > f :: Typeable (Proxy :: k -> *) => Proxy (Proxy :: k -> *) -> TypeRep > }}} > > Looks fine to me. Am I missing something? I'm happy with this type, it's very reasonable, and reflects the fact that some evidence (for `Typeable`) has to be provided by the caller. My main point was that this change will not be 100% backwards compatible (note that the new inferred type for `f` is different from what ghc 7.10 RC2 infers.) I was also slightly afraid that you might want to fudge things (by omitting the extra evidence from Haskell-level type signatures) to make the medium term solution fully backward compatible, but apparently that fear was unjustified. The open question is whether this incompatibility will affect existing real world code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 16:25:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 16:25:45 -0000 Subject: [GHC] #9004: Add sortOn function to Data.List In-Reply-To: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> References: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> Message-ID: <065.6b208c978c4b3779c0da8bf024f8d74b@haskell.org> #9004: Add sortOn function to Data.List -------------------------------------+------------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 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): * cc: ekmett (added) * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 16:28:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 16:28:37 -0000 Subject: [GHC] Batch modify: #7530, #8302, #9008, #9016, #9531, #9532, #9550 Message-ID: <20150205162837.BE5753A2FF@ghc.haskell.org> Batch modification to #7530, #8302, #9008, #9016, #9531, #9532, #9550 by hvr: keywords to report-impact -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 16:41:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 16:41:08 -0000 Subject: [GHC] Batch modify: #9385, #9586, #9588, #9590, #9664, #9816, #10039 Message-ID: <20150205164108.2CD1D3A2FF@ghc.haskell.org> Batch modification to #9385, #9586, #9588, #9590, #9664, #9816, #10039 by hvr: keywords to report-impact -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 16:41:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 16:41:24 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws In-Reply-To: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> References: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> Message-ID: <060.beef114803dd4d7f716d6a113dea73bc@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #10063 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: => #10063 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 16:45:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 16:45:12 -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.c276093a1a1d30599f0deeb8c43cfd17@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 oerjan): I agree with int-e that this might break some code, like his {{{ main = print (typeRep (Proxy :: Proxy Proxy)) }}} The problem is that in the old system, the `Typeable` instance is inferred with no need to consider the kind at all, so it becomes completely known at compile time. In the new system there will be an ambiguity. If my test with my mock implementation is any guide, GHC currently (well, 7.8.3) refuses to resolve such ambiguities. As I suggested in private, a case like the above might be fixed backwards- compatibly by making kinds in need of unavailable `Kindable` evidence default to `*` in a very similar way to numerical defaulting. I suspect that if a user isn't providing an explicit kind signature that is the most likely result they want anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 17:11:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 17:11:10 -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.fe4f47e2cf01140bb1601a61027ab9e3@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 int-e): Here is another testcase, geared towards motivating kind-level `Typeable` evidence (also known as `Kindable`): {{{ f :: Proxy (a :: k) -> Proxy (b :: k) -> Proxy (Proxy :: k -> *) f _ _ = Proxy g pa pb = typeRep (f pa pb) }}} If we allow kind-level `Typeable` constraints, i.e., `Typeable (k :: BOX)`, we would have {{{ g :: Typeable k => Proxy (a :: k) -> Proxy (b :: k) -> TypeRep }}} With just the type-level `Typeable`, we can choose between two constraints, {{{ g :: Typeable (Proxy (a :: k)) => Proxy (a :: k) -> Proxy (b :: k) -> TypeRep g :: Typeable (Proxy (b :: k)) => Proxy (a :: k) -> Proxy (b :: k) -> TypeRep }}} so which one should type inference prefer? Or would `g` require a type signature? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 17:36:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 17:36: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.b6837e1d3e0a41e714ad930160cf2ad1@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 goldfire): We are certainly not aiming for 100% backward compatibility. Indeed we can't -- `unsafeCoerce` compiles today, and we don't want it to compile tomorrow. So, at least that program will be omitted. Because of the conservative nature of type systems, some more programs will be excluded, most likely. We want this extra set to be small, but I'm not overly worried about it. As for this example: {{{ f :: Proxy (a :: k) -> Proxy (b :: k) -> Proxy (Proxy :: k -> *) f _ _ = Proxy g pa pb = typeRep (f pa pb) }}} I get {{{ g (pa :: Proxy a0) (pb :: Proxy b0) = typeRep <(k2 -> *) -> *> *) -> *>> *>> <$dict> (f pa pb) where $dict :: Typeable <(k2 -> *) -> *> (Proxy *>) }}} Unifying some variables and generalizing gives us {{{ g (pa :: Proxy (a :: k)) (pb :: Proxy (b :: k)) = typeRep <(k -> *) -> *> *) -> *>> *>> <$dict> (f pa pb) where $dict :: Typeable <(k -> *) -> *> (Proxy *>) }}} We then generalize over the `Typeable` constraint, giving {{{ g :: forall (k :: BOX) (a :: k) (b :: k). Typeable <(k -> *) -> *> (Proxy *>) => Proxy a -> Proxy b -> TypeRep }}} or, in source Haskell {{{ g :: Typeable (Proxy :: (k -> *) -> *) => Proxy (a :: k) -> Proxy (b :: k) -> TypeRep }}} Again, I don't see the ambiguity, and I think GHC would be able to infer this type without trouble... I don't see how this is a special case, really. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 18:30:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 18:30:35 -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.7fd166ce152003506bc7ebb1ccd36950@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 int-e): Replying to [comment:55 goldfire]: > {{{ > g :: Typeable (Proxy :: (k -> *) -> *) > => Proxy (a :: k) -> Proxy (b :: k) -> TypeRep > }}} > > Again, I don't see the ambiguity, and I think GHC would be able to infer this type without trouble... I don't see how this is a special case, really. You're right, it isn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:34:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:34:40 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.cc3f96f03267fab610825087e5d6e6f9@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | 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: Phab:D639 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:42:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:42:33 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.5e3ed3aa925054deb61f0112af7fd853@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | 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: Phab:D639 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"c88e11219c1e914b71d8c630a1f1d4f6f0fb6b9b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c88e11219c1e914b71d8c630a1f1d4f6f0fb6b9b" Bring Match m_fun_id_infix through the renamer. Summary: This is a first step for #9988 It turns out that bringing m_fun_id_infix through the renamer is actually very simple, affecting the internals of rnMatch' only. Is this simple enough to hit 7.10.1? Test Plan: ./validate Reviewers: hvr, simonpj, austin Reviewed By: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D639 GHC Trac Issues: #9988 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:42:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:42:33 -0000 Subject: [GHC] #10030: packageName for GHC.Generics.Datatype In-Reply-To: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> References: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> Message-ID: <060.b8d53de0f2736a8d14d120f39476f666@haskell.org> #10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | 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:D631 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"ae39c5c040f121947e14877c3ceb47bbe80c0ccb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ae39c5c040f121947e14877c3ceb47bbe80c0ccb" Add packageName to GHC.Generics.Datatype Summary: Added packageName to GHC.Generics.Datatype class definition Reviewers: hvr, dreixel, austin Reviewed By: dreixel, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D631 GHC Trac Issues: #10030 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:42:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:42:33 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.fbb3d3bd5a0fa6e4662a2c7744d3ba92@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.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 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7cf87fc6928f0252d9f61719e2344e6c69237079/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7cf87fc6928f0252d9f61719e2344e6c69237079" Eta-expand argument to foldr in mapM_ for [] Summary: This improves performance, at least sometimes--the previous implementation can be worse than the version in base 4.7. I have not had the time to run benchmarks and such, but `mapM` already does this. Also, inline `mapM_`, like `mapM`. Reviewers: hvr, nomeata, ekmett, austin Reviewed By: ekmett, austin Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D632 GHC Trac Issues: #10034 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:42:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:42:33 -0000 Subject: [GHC] #8796: -ddump-splices prints to error stream In-Reply-To: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> References: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> Message-ID: <063.a17961ab92599c1983c02df241e3a01f@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: 7.12.1 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:D627 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"73f976c47f00060baaeead9e0331ab265a84251c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="73f976c47f00060baaeead9e0331ab265a84251c" Make -ddump-splices output to stdout (fixes #8796) Summary: Fixes debug output so all info messages will use stdout. Fixes #8796. Make -ddump-splices output to stdout (fixes #8796) Make -dverbose-core2core use stdout (fixes #8796) Reviewers: simonpj, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D627 GHC Trac Issues: #8796 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:44:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:44:23 -0000 Subject: [GHC] #8796: -ddump-splices prints to error stream In-Reply-To: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> References: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> Message-ID: <063.84fb407f34705873304ac6e6facc0e7c@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: qnikst Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 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:D627 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:44:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:44:57 -0000 Subject: [GHC] #10030: packageName for GHC.Generics.Datatype In-Reply-To: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> References: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> Message-ID: <060.d27d8ceb713d38ae3326c8adc81d4fb9@haskell.org> #10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: libraries/base | 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:D631 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:47:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:47:36 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.f1db01fd24d7b4b0e44e7b30bb4efa10@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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:D639 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged into HEAD and 7.10 - thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:54:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:54:47 -0000 Subject: [GHC] #10066: Cross compiling from Linux to Windows fails Message-ID: <044.701b12e779da8e9491dc5f0c5a9e55b2@haskell.org> #10066: Cross compiling from Linux to Windows fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Building from git HEAD (daed18c35cda1) and configuring with: {{{ ./configure --target=i686-w64-mingw32 }}} The build then fails with: {{{ utils/hsc2hs/dist/build/Main.o: In function `c4tf_info': (.text+0x80a): undefined reference to `GetModuleFileNameW' }}} but earlier on there was other suspicious output like: {{{ utils/hsc2hs/Main.hs:234:1: Warning: the 'stdcall' calling convention is unsupported on this platform, treating as ccall When checking declaration: foreign import stdcall unsafe "static windows.h GetModuleFileNameW" c_GetModuleFileName :: Ptr () -> CWString -> Word32 -> IO Word32 }}} which suggests that the cross tool chain is not being used. However, the configure process did indeed find the right cross compilers and linkers. From the configure output: {{{ Building GHC version : 7.11.20150204 Git commit id : daed18c35cda114d8a5303bcb645195e1fd397e3 Build platform : x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : i386-unknown-mingw32 Bootstrapping using : /usr/bin/ghc which is version : 7.8.3 Using gcc : /usr/bin/i686-w64-mingw32-gcc which is version : 4.9.2 Building a cross compiler : YES cpp : /usr/bin/i686-w64-mingw32-gcc cpp-flags : -E -undef -traditional ld : /usr/bin/i686-w64-mingw32-ld -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:57:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:57:20 -0000 Subject: [GHC] #10066: Cross compiling from Linux to Windows fails In-Reply-To: <044.701b12e779da8e9491dc5f0c5a9e55b2@haskell.org> References: <044.701b12e779da8e9491dc5f0c5a9e55b2@haskell.org> Message-ID: <059.dc2d9068a2b270e944382f5834098085@haskell.org> #10066: Cross compiling from Linux to Windows fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd 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: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * owner: => erikd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 5 23:58:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Feb 2015 23:58:24 -0000 Subject: [GHC] #10066: Cross compiling from Linux to Windows fails In-Reply-To: <044.701b12e779da8e9491dc5f0c5a9e55b2@haskell.org> References: <044.701b12e779da8e9491dc5f0c5a9e55b2@haskell.org> Message-ID: <059.5e5082083f91aba6ec653f5d002b6aba@haskell.org> #10066: Cross compiling from Linux to Windows fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd 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: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Duplicate of #9524 yes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 00:00:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 00:00:18 -0000 Subject: [GHC] #10066: Cross compiling from Linux to Windows fails In-Reply-To: <044.701b12e779da8e9491dc5f0c5a9e55b2@haskell.org> References: <044.701b12e779da8e9491dc5f0c5a9e55b2@haskell.org> Message-ID: <059.d13d7a33fc4709d7c1a50ad53232ecac@haskell.org> #10066: Cross compiling from Linux to Windows fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => duplicate Comment: Yes, closing this as a dupe of #9524. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 00:06:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 00:06:25 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.126239ce92352fb2b869edcacdc76585@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 8718 | Test Case: Related Tickets: #2110 | tests/simplCore/should_run/T2110.hs | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by htebalaka): I'm a little out of my depth with rewrite rules, but is there anything preventing rules being associated with a typeclass? Then you could have zero method typeclasses like {{{ class Functor f => LawfulFunctor f where {-# RULES "fmap/coerce" fmap coerce = coerce #-} }}} and then any datatype that wants the rule just implements the typeclass, which is trivial. It would also address dfeuer's comment about lawfullness in constraints, though it would also generate a lot of noise in documentation (and might inherit the same issue with typeclasses that they can be hard to refactor). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 02:42:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 02:42:32 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries In-Reply-To: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> References: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> Message-ID: <061.ef03e8f19031c189abb42cbf465aa036@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 8718 | Test Case: Related Tickets: #2110 | tests/simplCore/should_run/T2110.hs | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:27 htebalaka]: > I'm a little out of my depth with rewrite rules, but is there anything preventing rules being associated with a typeclass? Then you could have zero method typeclasses like > {{{ > class Functor f => LawfulFunctor f where > {-# RULES "fmap/coerce" fmap coerce = coerce #-} > }}} > and then any datatype that wants the rule just implements the typeclass, which is trivial. It would also address dfeuer's comment about lawfullness in constraints, though it would also generate a lot of noise in documentation (and might inherit the same issue with typeclasses that they can be hard to refactor). I don't know too much about these things either, but I don't think this will work too well. The problem, as I understand it, is that the `LawfulFunctor` constraint has to be in place at the ''call site'', which will generally not be the case even when the functor is actually an instance of `LawfulFunctor`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 04:58:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 04:58:11 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow Message-ID: <045.2129a6dab0c443575ce604d52432a575@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Runtime Keywords: | performance bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The current implementation of the Read Integer instance has quadratic complexity and thus performs badly on large inputs. On my system, it takes 65 seconds to perform the following: {{{#!hs read (take 1000000 $ cycle "1234567890") :: Integer }}} Note that we already provide an ad-hoc instance for Show Integer, so maybe we can do the same for Read Integer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 05:07:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 05:07:18 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.923a4973ba3258392905c741785588bb@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Changes (by redneb): * differential: => Phab:D645 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 05:08:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 05:08:22 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.feab52179592a5b908786dbc21a231bf@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: libraries/base | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Changes (by redneb): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 06:41:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 06:41:23 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.5277663481f8b9da55d7325496f9b505@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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:D639 -------------------------------------+------------------------------------- Comment (by alanz): Thanks. I will complete #10061 after GHC 7.10 is out, I am using this time to make sure the API Annotations infrastructure is usable, while there is still an (ever diminishing) chance to do something about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 09:01:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 09:01:47 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.820853125303c751c40b2353854928e3@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: 7.10.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 simonpj): * priority: normal => highest Comment: I'm very unhappy with applying this patch without any comments, and without any understanding of what is going on. Now `mapM_` has an INLINE pragma that may or may not be necessary, and an eta-expanded argument, and no one understands which of the two is important, if either. Maybe there is a simplifier bug underlying this, which is simply being covered up. Please please can we have a reproducible test case that shows the regression. Ideally one that just showed it, but if it's necessary to switch Call Arity off (which you hypothesise is making the test case harder to create) then do that. But please let's NOT just cover up the problem. I'm quite inclined to revert the patch, just to serve as a forcing function to try to elicit this information. For now I'll just increase the priority to try to make sure we notice it. I know it's a nuisance, but this is an example of what people mean by incurring technical debt. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 09:47:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 09:47:39 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic Message-ID: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | 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: | -------------------------------------+------------------------------------- Currently in `base` we have * `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and `srcLocModule` * `Data.Typeable.Internals`: the data type `TyCon` contains `tyConPackage`, `tyConModule` and `tyConName. * `GHC.Generics`: the data type `Datatype` contains `dataTypePackage`, `dataTypeModule` and `dataTypeName` * `Data.Data`: the data type `DataType` (yes the capitalisation differs!) contains a field `tycon :: String`, and there are functions `tyconModule :: String -> String`, and `tyconUQname :: String -> String`, for parsing that string and extracting the module name and tycon name. * `GHC.StaticPtr`: the data type `StaticPtrInfo` contains `spInfoPackageKey`, `spInfoModuleName`, `spInfoName` (all `String`s). Oh, and `spInfoSrcLoc :: (Int,Int)` too! This is madness! Five different representations for the same information in one package! Let's fix this by defining some shared data types, for * `Module` = `ModuleName` + package * `Entity` = `Module` + unqualified name There would be a tiresome changeover period; but `Typeable` and `StaticPtr` are in flux anyway. Would anyone be willing to lead on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 09:56:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 09:56:07 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.6d0078238487a2ecb77ede9129cc83c9@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Changes (by simonpj): * cc: core-libraries-committee@? (added) * component: libraries/base => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 11:59:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 11:59:38 -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.86dff62279a4a44c247acd36f63d9243@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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): If they are different, don't merge them. If anyone wants to take this forward, the process is as usual: write a wiki page describing the design in detail; socialise it on ghc-devs and ghc-users, refine. Then implement. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 13:34:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 13:34:46 -0000 Subject: [GHC] #9099: Add strict fmap In-Reply-To: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> References: <045.7f6cb28f3b97baef1a99c0725efe4db9@haskell.org> Message-ID: <060.cae7f917054bf5b7b4d9cfd13b5333a9@haskell.org> #9099: Add strict fmap -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 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 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 13:49:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 13:49:15 -0000 Subject: [GHC] #7077: Add an order-reversing newtype to Data.Ord In-Reply-To: <043.e8a4759703eff2b2531ef28e260bd573@haskell.org> References: <043.e8a4759703eff2b2531ef28e260bd573@haskell.org> Message-ID: <058.4b73aeabe7b84be319d5ba33f14e214f@haskell.org> #7077: Add an order-reversing newtype to Data.Ord -------------------------------------+------------------------------------- Reporter: Azel | Owner: pcapriotti Type: feature request | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: Resolution: fixed | Keywords: ord Operating System: Unknown/Multiple | report-impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * keywords: ord => ord report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 13:54:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 13:54:00 -0000 Subject: [GHC] #7425: Add method to Data.Bits for creating zeroed values. In-Reply-To: <048.3f6fe538d67869b2ddc442a6058f7026@haskell.org> References: <048.3f6fe538d67869b2ddc442a6058f7026@haskell.org> Message-ID: <063.fd2411e819b7f3433a80054a9cb9c8f9@haskell.org> #7425: Add method to Data.Bits for creating zeroed values. -------------------------------------+------------------------------------- Reporter: Aninhumer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | 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): * cc: hvr, ekmett (added) * keywords: => report-impact * status: closed => new * resolution: wontfix => * milestone: => 7.8.1 Comment: This was discussed on the libraries list, http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21157 and https://www.haskell.org/pipermail/libraries/2014-March/022285.html and was finally implemented via 65d78ddf1fd58adea6e7cbc461a5683c9ad1f4cc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 13:54:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 13:54:19 -0000 Subject: [GHC] #7425: Add method to Data.Bits for creating zeroed values. In-Reply-To: <048.3f6fe538d67869b2ddc442a6058f7026@haskell.org> References: <048.3f6fe538d67869b2ddc442a6058f7026@haskell.org> Message-ID: <063.f77263574054995c0b16151ade10ccd0@haskell.org> #7425: Add method to Data.Bits for creating zeroed values. -------------------------------------+------------------------------------- Reporter: Aninhumer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 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): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 13:57:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 13:57:10 -0000 Subject: [GHC] #7424: Add Data.Bits instance for Bool In-Reply-To: <048.7371bd7dd98f3bd9a7a330cfd87f3e01@haskell.org> References: <048.7371bd7dd98f3bd9a7a330cfd87f3e01@haskell.org> Message-ID: <063.af382c1181e65c84685812b985d7c0da@haskell.org> #7424: Add Data.Bits instance for Bool -------------------------------------+------------------------------------- Reporter: Aninhumer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * status: closed => new * resolution: wontfix => Comment: This was proposed to the libraries list, see http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/20663 and passed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 13:57:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 13:57:49 -0000 Subject: [GHC] #7424: Add Data.Bits instance for Bool In-Reply-To: <048.7371bd7dd98f3bd9a7a330cfd87f3e01@haskell.org> References: <048.7371bd7dd98f3bd9a7a330cfd87f3e01@haskell.org> Message-ID: <063.176f210e5360547cecb926b27e76c35e@haskell.org> #7424: Add Data.Bits instance for Bool -------------------------------------+------------------------------------- Reporter: Aninhumer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 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 * status: new => closed * resolution: => fixed * milestone: => 7.8.1 Comment: implemented via 775d13d9c0d6d7247fb5ea6ed5ab973495dda58f -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 14:02:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 14:02:44 -0000 Subject: [GHC] #7817: Moving basic functions In-Reply-To: <045.6048e88ff843bd2359513bbb1acd3d52@haskell.org> References: <045.6048e88ff843bd2359513bbb1acd3d52@haskell.org> Message-ID: <060.3bbc96e9dcbd772439b1ddc8a50adaa4@haskell.org> #7817: Moving basic functions -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.2 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): * cc: hvr, ekmett (added) * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 14:05:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 14:05:18 -0000 Subject: [GHC] #7434: Add (&) to Data.Function In-Reply-To: <047.ec53f633601d3061c6a58c566fad4e07@haskell.org> References: <047.ec53f633601d3061c6a58c566fad4e07@haskell.org> Message-ID: <062.90cdc5c531557e6d6913cd808a05a839@haskell.org> #7434: Add (&) to Data.Function -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * status: closed => new * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 14:05:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 14:05:48 -0000 Subject: [GHC] #7434: Add (&) to Data.Function In-Reply-To: <047.ec53f633601d3061c6a58c566fad4e07@haskell.org> References: <047.ec53f633601d3061c6a58c566fad4e07@haskell.org> Message-ID: <062.812386b02a1d489d59d3c201c035386f@haskell.org> #7434: Add (&) to Data.Function -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9008 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => duplicate * related: => #9008 Comment: this was actually addressed via #9008 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 14:08:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 14:08:34 -0000 Subject: [GHC] #5593: Proposal: Remove Num superclass of Bits In-Reply-To: <049.c6204d00ad580f2365fec2c986672cd6@haskell.org> References: <049.c6204d00ad580f2365fec2c986672cd6@haskell.org> Message-ID: <064.784594514b7e0753059a3fe5fe89ad96@haskell.org> #5593: Proposal: Remove Num superclass of Bits -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 7.2.1 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): * cc: hvr, ekmett (added) * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 14:09:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 14:09:06 -0000 Subject: [GHC] #5414: Add unsafeShift to Data.Bits In-Reply-To: <044.c1b47a93a369d6cffc160f931d26311e@haskell.org> References: <044.c1b47a93a369d6cffc160f931d26311e@haskell.org> Message-ID: <059.22a6d271a44474b24cd11881dcea56c5@haskell.org> #5414: Add unsafeShift to Data.Bits -------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 7.4.1 Component: libraries/base | Version: 7.2.1 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): * cc: hvr, ekmett (added) * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 14:10:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 14:10:43 -0000 Subject: [GHC] #4865: Deprecate and remove Prelude.catch and System.IO.Error.{catch, try} In-Reply-To: <044.509d5e35dde3bc2bc27e6c4a1253faa4@haskell.org> References: <044.509d5e35dde3bc2bc27e6c4a1253faa4@haskell.org> Message-ID: <059.5596db660e39494982a643ca41ee3cf9@haskell.org> #4865: Deprecate and remove Prelude.catch and System.IO.Error.{catch,try} -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 7.0.1 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): * cc: hvr, ekmett (added) * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:03:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:03:24 -0000 Subject: [GHC] #10050: template haskell Ppr missing parentheses for SigT In-Reply-To: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> References: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> Message-ID: <060.e26c9f8d81c711c8501957294ee4911e@haskell.org> #10050: template haskell Ppr missing parentheses for SigT -------------------------------------+------------------------------------- Reporter: aavogt | 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:"111e5870803bcccd1c0736fdba432f8f9410454f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="111e5870803bcccd1c0736fdba432f8f9410454f" Put parens around (ty :: kind) when pretty-printing TH syntax See Note [Pretty-printing kind signatures] in Language.Haskell.TH.Ppr.hs, and Trac #10050. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:03:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:03:25 -0000 Subject: [GHC] #10020: GHC 7.10 rejects nullary type class with associated data In-Reply-To: <050.7fe5de35678625902ef8dada7748ae56@haskell.org> References: <050.7fe5de35678625902ef8dada7748ae56@haskell.org> Message-ID: <065.aaed1f2f7225533646895748e42239bf@haskell.org> #10020: GHC 7.10 rejects nullary type class with associated data -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"dda652826326022e4604d7b0fdc82c1993e32a67/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dda652826326022e4604d7b0fdc82c1993e32a67" Fix the nullary-type-class case for associated types It was already ok for methods. Fixes Trac #10020 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:05:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:05:43 -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.e7c0ebfa143a2217cb312648053dd439@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | 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 simonpj): Peter Wortman says: We are clearly trying to float past a breakpoint here, which is simply impossible. Pretty sure this would have been a panic before my changes too (it would have tried to "mkNoCount" the breakpoint). Guess I was wrong reading a "breakpoints don't appear here" invariant out of that... The quick fix would be to drop all floats in-place: {{{ -- scoped, counting and unsplittable, can't be floated through | otherwise = floatBody tOP_LEVEL expr }}} This fixes the panic, but is a bit awkward. Probably better to change `SetLevels`? Not a piece of code I'm very familiar with... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:07:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:07: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.06481281c66497ef9d76b95eb795c9d3@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | 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 simonpj): Peter says (further) > Why do you say "we are clearly trying to float past a breakpoint"? Why is it so clear? It's the only kind of `Tickish` that is scoped, counting and not splittable. This means that we can't * Simply float code out of it, because the payload must still be covered (scoped) * Copy the tick, because it would change entry counts (here: duplicate breakpoints) > Why is it wrong to float a lazy thunk out of a breakpoint? Good questions - I haven't given breakpoint semantics a lot of thought, to be honest. My assumption was that most optimisation passes would never see them. And where they did, they should just leave them in peace as much as possible. For whatever it's worth, the source cautions against making breakpoints unscoped: {{{ -- Breakpoints are scoped: eventually we're going to do call -- stacks, but also this helps prevent the simplifier from moving -- breakpoints around and changing their result type (see #1531). }}} Hm. We might try to make them pseudo-splittable, with non-counting breakpoints being NOPs for now? This might still allow us to implement breakpoint-based stack traces if we really want them... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:08:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:08:17 -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.12f5e8d0aed2454610399e9fc4f784f8@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar, Type: bug | peter wortman Priority: high | Status: new Component: Compiler | Milestone: 7.10.1 Resolution: | Version: 7.10.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonmar, peter wortman * priority: normal => high * milestone: => 7.10.1 Comment: Peter, Simon M: can you work together to fix this? A flat-out panic is really not good. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:08:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:08:59 -0000 Subject: [GHC] #10050: template haskell Ppr missing parentheses for SigT In-Reply-To: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> References: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> Message-ID: <060.0e7c679f7a973c5b613fca11ab299566@haskell.org> #10050: template haskell Ppr missing parentheses for SigT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: merge 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 simonpj): * status: new => merge Comment: Thanks for reporting this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:10:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:10:21 -0000 Subject: [GHC] #10020: GHC 7.10 rejects nullary type class with associated data In-Reply-To: <050.7fe5de35678625902ef8dada7748ae56@haskell.org> References: <050.7fe5de35678625902ef8dada7748ae56@haskell.org> Message-ID: <065.9a1d3c0e893d3550bc2a0f0c73228245@haskell.org> #10020: GHC 7.10 rejects nullary type class with associated data -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: indexed- Blocked By: | types/should_compile/T10020 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => indexed-types/should_compile/T10020 Comment: Thanks for reporting this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:15:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:15:25 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310041=3A_Instance_signatures_=28Ins?= =?utf-8?b?dGFuY2VTaWdzKSBkb24ndCBhY2NlcHQgJ1tdIDo6IFvEuF0=?= In-Reply-To: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> References: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> Message-ID: <066.8aecaf3cef16ab24c69f4fa9d6156a8e@haskell.org> #10041: Instance signatures (InstanceSigs) don't accept '[] :: [?] -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Blocked By: | Related Tickets: #9582 #9833 | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0f75a3f0a15ac26e52dc3477fd6e5bc3cd5c6eca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0f75a3f0a15ac26e52dc3477fd6e5bc3cd5c6eca" Test Trac #10041 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:16:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:16:59 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310041=3A_Instance_signatures_=28Ins?= =?utf-8?b?dGFuY2VTaWdzKSBkb24ndCBhY2NlcHQgJ1tdIDo6IFvEuF0=?= In-Reply-To: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> References: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> Message-ID: <066.a27b7311c83c5caad0a96989d8a9dc61@haskell.org> #10041: Instance signatures (InstanceSigs) don't accept '[] :: [?] -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: fixed | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | polykinds/T10041 valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #9582 #9833 | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T10041 * resolution: => fixed Comment: Happily, some work I did on instance signatures (yes it was #9582) seems to have cured this. At least, HEAD is fine. And the 7.10 branch is fine too. Thanks for reporting. I've added a regression tests. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:37:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:37:47 -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.5cc1542f75651d374ae186520ea7d42e@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new 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: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: scpmw (added) * owner: simonmar, peter wortman => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:52:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:52: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.d3290d9e2cc638051d8f7245c611fa47@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 oerjan): Replying to [comment:55 goldfire]: > Again, I don't see the ambiguity, and I think GHC would be able to infer this type without trouble... I don't see how this is a special case, really. With that example, I've mostly been convinced that constraints separating out kinds aren't necessary. I still think it would help backwards compatibility if kinds in `Typeable` contexts defaulted to `*` in situations exactly analogous to when types with numerical contexts do. Once again, int-e's test case is illustrative: {{{ main :: IO () main = print (typeRep (Proxy :: Proxy Proxy)) }}} As far as I understand, without the type signature a solver would infer a type of {{{ main :: Typeable (Proxy :: k -> *) => IO () }}} and by defaulting `k` to `*` the code would still work, and probably do what was originally intended. Without defaulting it seems to me that it cannot work either with or without a signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 15:56:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 15:56:15 -0000 Subject: [GHC] #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.b773fda6825bcaf82d7c0bc8cd89d703@haskell.org> #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+-------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+-------------------------------- Comment (by juhpetersen): idris also crashes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 16:55:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 16:55:09 -0000 Subject: [GHC] #10004: rec {} causes "head:empty list" exception In-Reply-To: <044.6292d003c0954df796402481444e8d4b@haskell.org> References: <044.6292d003c0954df796402481444e8d4b@haskell.org> Message-ID: <059.d6b359cbcd50e36b7fb52e32335a0435@haskell.org> #10004: rec {} causes "head:empty list" exception -------------------------------------+------------------------------------- Reporter: alanz | 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: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"43636e1b8cf4a6d4752a22b098a9edd0759a7600/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="43636e1b8cf4a6d4752a22b098a9edd0759a7600" Fix Trac #10004: head [] exception when using recursive mdo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 16:56:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 16:56:29 -0000 Subject: [GHC] #10004: rec {} causes "head:empty list" exception In-Reply-To: <044.6292d003c0954df796402481444e8d4b@haskell.org> References: <044.6292d003c0954df796402481444e8d4b@haskell.org> Message-ID: <059.60cb41985b4bfa299fdb3c380df8e1e3@haskell.org> #10004: rec {} causes "head:empty list" exception -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: merge Priority: normal | 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: | mdo/should_compile/T10004 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => mdo/should_compile/T10004 * milestone: => 7.10.1 Comment: Good point. Fixed, thank you Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 16:58:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 16:58:56 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.b2f585420bff2d9d9efd8cbf3900f440@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Comment (by ekmett): I have no principled objection to dramatically reducing the asymptotic cost of parsing integers assuming of course in good faith that the patch works. That said, it seems like it'd be a good idea to apply the same reasoning to the new `Natural` type that Herbert added in 7.10 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 17:21:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 17:21:15 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.a8bb1eb2e75302c122f357fcae47ab82@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Comment (by redneb): I only ommited `Natural` because the read instance for it relies on the read instance of `Integer` and therefore it will befenefit from my patch anyway. But I agree that it would be a good idea to start treating `Natural` as a first class citizen. So what's the policy here? Do I need to `CPP`/`#ifdef` this, or is that unnecessary since they are from the same package anyway? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 18:40:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 18:40:12 -0000 Subject: [GHC] #10029: internal error: evacuate(static): strange closure type 62744 (was: unit-tests: internal error: evacuate(static): strange closure type 62744) In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.461c3ebcd0bbcff914c6aa846af062ec@haskell.org> #10029: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+-------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+-------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 6 18:43:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Feb 2015 18:43:26 -0000 Subject: [GHC] #10029: ARM: internal error: evacuate(static): strange closure type 62744 (was: internal error: evacuate(static): strange closure type 62744) In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.a310a28043bc379b4c47febba346b3e5@haskell.org> #10029: ARM: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+-------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+-------------------------------- Comment (by juhpetersen): The current patches that Fedora is using for ghc-7.8.4: http://pkgs.fedoraproject.org/cgit/ghc.git/tree/?id=1cb2f64c617956b34befcc955cd63593fc4c74b8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 7 11:33:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Feb 2015 11:33:17 -0000 Subject: [GHC] #9204: Conflicting definition in hs-boot file In-Reply-To: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> References: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> Message-ID: <063.99a79fad2c92c0ebe2f591e8a5f83ee6@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | 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: | roles/should_fail/T9204 | Blocking: | Differential Revisions: Phab:D458 -------------------------------------+------------------------------------- Comment (by phischu): In the following example the complete data declaration happens to be present in the hs-boot file: Foo.hs: {{{ module Foo where import Bar data P a = P }}} Foo.hs-boot: {{{ module Foo where data P a = P }}} Bar.hs: {{{ module Bar where import {-# SOURCE #-} Foo }}} Could you now do role inference in the hs-boot file as well, so that the example compiles? My use-case is that I generate hs-boot files by copying whole declarations. Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 7 18:06:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Feb 2015 18:06:45 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.dbcd7cab6328cc430bc3780d5fa4f3be@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Comment (by redneb): One problem with `Natural` is that it does not follow the conventions of other numeric types. For example, the `Show` instances of all other types are given in `GHC.Show` and the `Read` instances in `GHC.Read`, while for `Natural` all instances are declared in `GHC.Natural`. Herbert, do you have any objection moving the `Read Natural` instance to `GHC.Read`? This will make it easier to treat `Natural` like any other type in the future. Otherwise, there will be an module import cycle and will require an hs- boot file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 7 19:11:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Feb 2015 19:11:14 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements In-Reply-To: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> References: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> Message-ID: <060.eeba78b1aae2880217059343d29cb43f@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): this actually impacts the vector package, and possibly other code https://github.com/haskell/vector/issues/75#issuecomment-73367157 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 7 19:19:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Feb 2015 19:19:17 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements In-Reply-To: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> References: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> Message-ID: <060.a461d1501d9cd79071cefad35242753a@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): its probably too late to get this this fixed up for 7.10, but i think this should definitely happen for 7.12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 7 19:20:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Feb 2015 19:20:07 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements In-Reply-To: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> References: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> Message-ID: <060.0788dc21bada555304e157d2befdfca9@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by carter): * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 7 21:51:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Feb 2015 21:51:17 -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.7656ad39b8c0646f97cbb1cfb6bbe953@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 goldfire): This defaulting to `*` is precisely what happens without `PolyKinds` on. So anyone not worried about kind variables won't need to. But I don't like this defaulting behavior if `PolyKinds` ''is'' on. If a user has specified `PolyKinds` and writes the code in comment:57, I would want an error to be reported. The choice of the kind variable here is potentially relevant to the programmer's desired behavior, and I think silently guessing a value is wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 7 23:11:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Feb 2015 23:11: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.323a7e1b9642fce510daae7100566ef5@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 oerjan): Replying to [comment:58 goldfire]: > This defaulting to `*` is precisely what happens without `PolyKinds` on. So anyone not worried about kind variables won't need to. Oh, so it is, on second testing. My first test (with my mock implementation, whose inferred types I think are "close enough" for the purpose) failed, but I only removed `PolyKinds` and must have left some other extension that implied it. > But I don't like this defaulting behavior if `PolyKinds` ''is'' on. If a user has specified `PolyKinds` and writes the code in comment:57, I would want an error to be reported. The choice of the kind variable here is potentially relevant to the programmer's desired behavior, and I think silently guessing a value is wrong here. Good point, although I'm still wondering which option will break the least code... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 00:09:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 00:09:51 -0000 Subject: [GHC] #9204: Conflicting definition in hs-boot file In-Reply-To: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> References: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> Message-ID: <063.e90335ed5d2aec3a5f732204e3c77ecc@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | roles/should_fail/T9204 | Blocking: | Differential Revisions: Phab:D458 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: goldfire => * priority: normal => low * status: closed => new * resolution: fixed => * milestone: => 7.12.1 Comment: Yes, the suggestion in comment:8 is reasonable: Use `phantom` as the default role in hs-boot files when the definition is supplied. Even today, GHC does do role inference in hs-boot files -- it just uses a different default. But there is no reason to change the default if a definition is supplied. Thanks for the suggestion. However, because this is a user-facing change, it's not appropriate (in my opinion) to make the change for 7.10. And, it's just barely possible that this will break code. The following compiles today: A.hs-boot: {{{ module A where data P a = P }}} A.hs: {{{ module A where type role P representational data P a = P }}} Under the proposed change, this example would fail due to the missing role annotation in the hs-boot file. That said, I'm still in favor of the change, just documenting what would break. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 00:10:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 00:10:11 -0000 Subject: [GHC] #9204: Conflicting definition in hs-boot file In-Reply-To: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> References: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> Message-ID: <063.7f7840bec25286f04b1e3fae83a2f469@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | roles/should_fail/T9204 | Blocking: | Differential Revisions: Phab:D458 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 00:13:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 00:13:14 -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.24124650078561c0ab07d5b4aaf96611@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 goldfire): I think your plan (of more defaulting to `*`) would break less code, but I think that someone saying `Proxy Proxy` without thinking about kinds yet specifying `PolyKinds` has made a mistake. After all, the goal is to make the `TypeRep` for `Proxy :: * -> *` and `Proxy :: Bool -> *` different. We should expect the user to specify which one they want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 00:24:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 00:24:41 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements In-Reply-To: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> References: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> Message-ID: <060.e573875222feb4b39b44476bc7b203d3@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Yuras): This issue is wider then the one in `vector`. All the `Foreign` API that works with `Storable`, assumes alignment to be limited to the largest possible value for non-SIMD types. And `malloc` allocates memory block, suitable for any such `Storable` instance, that is why it ignores alignment. Note: `malloc` is implemented via C function with the same name, and the behavior is actually inherited from C standard lib, see [[http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html|here]]. To allow large alignments we need to use either `posix_memalign` or other platform specific API. It is important that `posix_memalign` returns a pointer, that can be deallocated via C function `free`, see [[http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html|here]]. But unfortunately portability might be an issue, see [[http://www.gnu.org/software/gnulib/manual/html_node/posix_005fmemalign.html|here]]. (Also it might be slower, but I didn't try it myself.) Other platform specific functions return pointers that can't be deallocated via `free` function from C stdlib. We can change `free` not to use the C `free` function. But that will break a lot of code that uses `free` to deallocate memory that comes from C, and uses `malloc` to allocate memory that will be deallocated in C via C function. Yes, that code is already broken, because it does silly things, but it is common enough to care. Also `realloc` will be problematic too, because the corresponding C function doesn't support unusual alignment. Probably other functions will break too. I'd propose to reclassify the issue to documentation bug. All SIMD code should use special API to allocate and deallocate memory. It is probably possible to fix `vector` to handle large alignments, but it will introduce inconsistency into API. Sorry for long comment, and please correct me if I'm missing something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 01:39:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 01:39:19 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.6c1d2accca009473b2f7e184b595a661@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: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]). But, there is some subtlety. GHC assumes all function types (that is, types with kinds that are headed by `->`) are ''generative'' and ''injective''. Generativity means that, given `a b ~ c d`, you can conclude `a ~ c`. Injectivity means that, given `a b ~ a d`, you can conclude `b ~ d`. Indeed, putting these together and assuming `a b ~ c d`, you can conclude `b ~ d`. Thus, the kind `->` denotes a generative, injective function. We could imagine a new classifier `~>` that denotes an ordinary function, with no assumptions. GHC would then be careful not to decompose such things. This is exactly the situation today with type families. Note that, short of GHCi's `:kind` command, there is no way to work with the kind of an unapplied type family. If I say `type family F (a :: *) :: *`, we often colloquially say that `F :: * -> *`, but there is no way to use this knowledge in a Haskell program, because `F` can never appear unsaturated. Thus, it is more accurate to say that `F` is just ill-formed, and `F a :: *` as long as `a :: *`. All of this is to say that the new arrow would have to denote ''non''-injective functions. And, I could easy say that GHC today supports such a thing, because there's no way to take advantage of it anyway. What we really need in this direction is unsaturated type functions, but that's a story for another day. (A story I'd love to think more about... on that other day!) So, taking all of this into account, dorchard's proposal is a different syntax for denoting injectivity, and I personally prefer the functional- dependency-like one more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 05:13:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 05:13:07 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements In-Reply-To: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> References: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> Message-ID: <060.786acfbee0b08858441a6d4d845d4026@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): hrm, you do raise a good point that we should try to understand which platforms / OS versions GHC 7.12 or whatever will support that dont have a posix_memalign feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 11:53:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 11:53:31 -0000 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@haskell.org> References: <044.ae4012da6404813e981e2064d26c5c85@haskell.org> Message-ID: <059.232b5fbf7346bc1431c666e0cd4e7007@haskell.org> #2917: alloca and allocaArray do not respect alignment -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: Compiler (FFI) | Version: 6.12.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: reported as #9806 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 11:54:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 11:54:10 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements In-Reply-To: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> References: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> Message-ID: <060.c6b489b1196bd92a9e03da65ebbc0360@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | 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: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: We had an old ticket about this (which I've just closed as a dup of this one): #2917 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 11:54:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 11:54:23 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements In-Reply-To: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> References: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> Message-ID: <060.31ddea91fd2005192d46c1587e11d0c2@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * owner: ekmett => * status: closed => new * resolution: duplicate => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 16:01:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 16:01:07 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements In-Reply-To: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> References: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> Message-ID: <060.d928bad761896bae5dca43740937e1ea@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): I'd like to point out that the posix standard SPECIFICALLY specifies that `free` is the function that must be used to deallocate `posix_memalign` allocated memory http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_memalign.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 17:11:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 17:11:41 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements In-Reply-To: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> References: <045.326ba18e768a85e91e35911674b0f3ff@haskell.org> Message-ID: <060.fbee63ad463d073e889501b76df9662a@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Yuras): Sorry my broken Engligh. Yes, `posix_memalign` requires `free` for deallocation, but I was trying to say, that we have to use other API on platforms that don't have `posix_memalign`. E.g. `pagealign_alloc` requires `pagealign_free`. If we provide strong alignment guarantees for `malloc`, then we should be able to implement that on all current and future platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 8 18:12:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Feb 2015 18:12:41 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.b10a2a3c2140bbbc942a40cb7e4c7aab@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Comment (by ekmett): I'm pretty sure we'd be willing to bend over backwards to avoid adding another import cycle, given all that we've done over the course of 7.10 to break the previous ones up. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 04:27:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 04:27:23 -0000 Subject: [GHC] #9337: Add `sortOn` function to Data.List In-Reply-To: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> References: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> Message-ID: <065.eccca479ca87d84a8a9cc5b0d8cd93f6@haskell.org> #9337: Add `sortOn` function to Data.List -------------------------------------+------------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | 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: #9004 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by JohnWiegley): This is also a dupe of part of #2659, which was closed 5 years ago now as wontfix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 04:41:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 04:41:50 -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.993df93d934216afbc37e3e71f8897ea@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: new 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 erikd): Working on a patch for this. Have actually made is past the `hsc2hs` part, but don't have a complete build yet. @rwbarton : Mind if I steal this ticket ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 04:55:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 04:55:08 -0000 Subject: [GHC] #10069: CPR related performance issue Message-ID: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- By default CRP analysis can be too aggressive in trying to pass as much as possible in unboxed tuples, in general it's not a problem but when one big datatype is passed to several consumers it might end up pushed to stack several times instead of once - to heap, things are getting worse when there are sufficient fields to cause stack overflow which otherwise is possible to avoid - in our codebase adding one field with ExistentialQuantification (unused, but that prevents ghc from doing CRP transformation) reduces number of stack overflow by a factor of 1000 and increases overall performance by 10%. In provided example performance for both A and B should be identical and yet B is consistently faster by 3-5% It's possible to increase this performance gap by adding more and more fields. I was able to replicate this issue in ghc 7.8.3 and 7.10,1rc2 {{{#!hs {-# LANGUAGE ExistentialQuantification #-} module Blah where import Criterion import Criterion.Main import Data.Typeable data A = A () !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int data B = forall rep. (Typeable rep) => B rep !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int a :: A a = A () 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 b :: B b = B () 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 {-# NOINLINE a1 #-} a1 :: A -> Int a1 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f1 {-# NOINLINE a2 #-} a2 :: A -> Int a2 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f2 {-# NOINLINE a3 #-} a3 :: A -> Int a3 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f3 {-# NOINLINE a4 #-} a4 :: A -> Int a4 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f4 {-# NOINLINE b1 #-} b1 :: B -> Int b1 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f1 {-# NOINLINE b2 #-} b2 :: B -> Int b2 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f2 {-# NOINLINE b3 #-} b3 :: B -> Int b3 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f3 {-# NOINLINE b4 #-} b4 :: B -> Int b4 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f4 {-# NOINLINE fa #-} fa :: A -> Int fa a = a1 a + a2 a + a3 a + a4 a {-# NOINLINE fb #-} fb :: B -> Int fb b = b1 b + b2 b + b3 b + b4 b main :: IO () main = defaultMain [ bgroup "single call" [ bench "A" $ whnf fa a , bench "B" $ whnf fb b ] ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 05:00:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 05:00:04 -0000 Subject: [GHC] #9337: Add `sortOn` function to Data.List In-Reply-To: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> References: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> Message-ID: <065.fdc43b150f73ad4c29a9ddbafd6e3d0b@haskell.org> #9337: Add `sortOn` function to Data.List -------------------------------------+------------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | 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: #9004, #2659 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * related: #9004 => #9004, #2659 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 07:20:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 07:20:55 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.d8c69403081925dbd34ea88f42433768@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 akio): * cc: tkn.akio@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 08:34:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 08:34:33 -0000 Subject: [GHC] #9204: Conflicting definition in hs-boot file In-Reply-To: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> References: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> Message-ID: <063.bc99e6814bc95b84b4a3a7d6595c33b3@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | roles/should_fail/T9204 | Blocking: | Differential Revisions: Phab:D458 -------------------------------------+------------------------------------- Comment (by simonpj): OK let's change this for 7.12, and document the change. Richard, you took ownership, so maybe do this whenever it's convenient to you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 08:37:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 08:37:57 -0000 Subject: [GHC] #4834: New Functor => Applicative => Monad Hierarchy In-Reply-To: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> References: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> Message-ID: <059.f75c5bbeae05a15ee2fde288710f95f5@haskell.org> #4834: New Functor => Applicative => Monad Hierarchy -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: 7.0.1 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004 | Test Case: | Blocking: | Differential Revisions: Phab:D13 -------------------------------------+------------------------------------- Changes (by hvr): * status: closed => new * cc: ekmett, thoughtpolice, hvr (added) * type: proposal => task * differential: => Phab:D13 * related: => #8004 * priority: normal => high * milestone: Not GHC => 7.10.1 * keywords: => report-impact * resolution: invalid => Comment: Reusing this old AMP ticket so I don't have to create a new one to track AMP progress; AMP phase 1 was covered by #8004, while this ticket is about phase 3 (actually implementing the change) The AMP was implemented in a single monolithic commit, followed by AMP- related follow-up patches fixing up things as well as generalising some type signatures from Monad to Applicative: - d94de87252d0fe2ae97341d186b03a2fbe136b04 ("Make Applicative a superclass of Monad") - 65f887e1a0d864526f6a2609a3afc2c151c25e38 ("base: Add some notes about the default impl of `(>>)`") - 6477b3dc058a92b825ef30d98797603b4a44a001 ("testsuite: AMPify ioprof.hs") - 29e50da4c274eba0e444ce4b95294a76832908f2 ("testsuite: AMPify T3001-2") - f636faa7b2b7fc1d0663f994ad08f365d39a746d ("Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA`") - a07ce1654ac5b8033f2daf9270c6e182415b69ca ("Generalise `Control.Monad.{when,unless,guard}`") - bf3329104c971c84ab178f3ded88254b9594f9cc ("Generalise `guard` for real this time") - a1b539142d7853bc02c36f1b3e8d489a9864f0e9 ("testsuite: fix T5751 build failure (AMP)") - b30b185e5c653dfed948d71ce2336be70be3b418 ("testsuite: fix T1735_Help/State.hs build failure (AMP)") - abba3812e657a5267bba406d2c877c1cb5d978f9 ("Improve Applicative definitions") -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 08:39:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 08:39:42 -0000 Subject: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1) In-Reply-To: <045.ee77ea6713da1cec5c3314c4ae999d7f@haskell.org> References: <045.ee77ea6713da1cec5c3314c4ae999d7f@haskell.org> Message-ID: <060.2a84dc99c5f0cdf445670c995d82ba10@haskell.org> #8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4834 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: => #4834 Comment: Phase 3 is covered by the (re-purposed) #4834 ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 08:40:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 08:40:41 -0000 Subject: [GHC] #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) (was: New Functor => Applicative => Monad Hierarchy) In-Reply-To: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> References: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> Message-ID: <059.d9a447359a2331ba0ad95b55540b802d@haskell.org> #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: 7.0.1 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004 | Test Case: | Blocking: | Differential Revisions: Phab:D13 -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 08:43:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 08:43:49 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.a28a186c05b213de57df1c661bcc2908@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: low => high * milestone: => 7.10.1 Comment: Uh, my first impression honestly is this has the potential to be really bad - I'd guess most people constrain `Read` to `Int` in cases like this, but I could fathom a case where e.g. a webserver took an integer somewhere in an HTTP request and used `Read`, which could lead to an easy denial of service. I'm fine with shuffling to avoid boot files/cycles and whatnot. Do update the patch please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 08:49:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 08:49:11 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.5f010483236bc94d7c5a3830813da128@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:6 redneb]: > Herbert, do you have any objection moving the `Read Natural` instance to `GHC.Read`? This will make it easier to treat `Natural` like any other type in the future. I have no hard objection, only a soft one: Right now, `GHC.Natural` is a neat independent leaf-module in the import- graph. By defining the Natural instance in `GHC.Read`, it would lose that property, and I'm not sure what else you'd need to transform in the import graph to make that happen. Is there a real benefit from moving the instance from the data-type module to the class module? Or is this just about aesthetics? > Otherwise, there will be an module import cycle and will require an hs- boot file. In any case, if possible make the `Natural` change a separate commit if possible so we can see more easily what import-related shuffling was needed to accomplish that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:04:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:04:38 -0000 Subject: [GHC] #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) In-Reply-To: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> References: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> Message-ID: <059.2f4a12e3711b93137e88532cc725baba@haskell.org> #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: 7.0.1 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004 | Test Case: | Blocking: | Differential Revisions: Phab:D13 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a741e69a230eb6d6e3373ad1fbe53c73b5f95077/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a741e69a230eb6d6e3373ad1fbe53c73b5f95077" Provide default implementation of `Monad(return)` This was dropped last-minute from d94de87252d0fe2ae97341d186b03a2fbe136b04 (re #4834) together with the default implementation for `(>>)` (see 65f887e1a0d864526f6a2609a3afc2c151c25e38 for explanation). However, the risk of accidental mutually recursive definitions of `return`/`pure` is rather low as unlike with the `(>>) = (*>)` default, any cyclic definitions would necessarily wind up being new ones, rather than changing the semantics for old operations and introducing bottoms. On the other hand, not having the default method implementation in place in GHC 7.10 would complicate/delay any future attempt to clean-up the `Monad`-class. This finally allows (for `base >= 4.8`) to define a F/A/M instance-chain with the following minimal definitions (while ignoring that `return` is still a class-method in `Monad`) instance Functor M where fmap = ... instance Applicative M where pure = ... (<*>) = ... instance Monad M where (>>=) = ... Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D647 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:06:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:06:47 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.2c86fc4c2f70ce8c5753aaec609d10fb@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: high => normal * milestone: 7.10.1 => 7.12.1 Comment: Since this seems to be a regression, but also something of a corner case involving recursive type families, I'm pushing this one out to 7.12 and 'normal' priority (as 7.10 is feature complete). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:08:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:08:19 -0000 Subject: [GHC] #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) In-Reply-To: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> References: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> Message-ID: <059.bdd80256078381b3de69367c765d3ce9@haskell.org> #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: 7.0.1 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004 | Test Case: | Blocking: | Differential Revisions: Phab:D13 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:10 Herbert Valerio Riedel ]: > In [changeset:"a741e69a230eb6d6e3373ad1fbe53c73b5f95077/ghc"]: ...also merged to ghc-7.10 via 262f7a85bb1d40770245b990527eb0bee7c20195 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:08:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:08:31 -0000 Subject: [GHC] #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) In-Reply-To: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> References: <044.b288d9f061683e6ec56e4e928c22656e@haskell.org> Message-ID: <059.5e68a439af500703d7872a5d61afab26@haskell.org> #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: task | Status: closed Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: 7.0.1 Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004 | Test Case: | Blocking: | Differential Revisions: Phab:D13 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:08:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:08:50 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.797d1fcd8e7f6e43810de7855f1a7450@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 Comment: (Pushing back to 7.12 pending investigation on this ticket and #8224). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:09:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:09:12 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.9d415c46e64e29c2fe1dd736e7f9e340@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Operating System: Linux | Manager, System Time Type of failure: Runtime | Architecture: x86_64 performance bug | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 Comment: (Pushing back to 7.12 as this ticket requires more investigation for a fix.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:12:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:12:19 -0000 Subject: [GHC] #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied In-Reply-To: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> References: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> Message-ID: <061.7327460a04f64365505283d3072c150a@haskell.org> #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | 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: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 Comment: Moving to 7.12, as this doesn't look like it will be fixed in the 7.10 timeframe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:14:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:14:19 -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.e0f8d3ddd0c54f547328ee7f0af5bf41@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: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 Comment: So the short-term problem here is fixed, but the long-term fixes are still needed, so I'm bumping this to 7.12 for future work by Pedro. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:37:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:37:05 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.42cbe513940feca5c0246edde6ab6f90@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h -------------------------------------+------------------------------------- Reporter: asr | 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 Comment: Moving to 7.12 for now. FWIW, I can't quite tell if `cpphs` correctly handles this `#if define` syntax (which I assume traditional CPP does), meaning maybe upstream should fix it, but I don't think at the moment it's going to break anything severe based on this example. OTOH, this can probably be mitigated by modifying the rules to generate `ghcautoconf.mk`, which is actually a copy of some autoconf output created during the build; a `sed` invocation could probably do it - the rule to generate ghcautoconf is in `includes/ghc.mk` (search for `__GHCAUTOCONF_H__`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:49:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:49:14 -0000 Subject: [GHC] #10004: rec {} causes "head:empty list" exception In-Reply-To: <044.6292d003c0954df796402481444e8d4b@haskell.org> References: <044.6292d003c0954df796402481444e8d4b@haskell.org> Message-ID: <059.780d57ca09ca0230ff5df7c81a386a8a@haskell.org> #10004: rec {} causes "head:empty list" exception -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: closed Priority: normal | 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: | mdo/should_compile/T10004 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via 3748c7311f3b657a9b3c01a48b39874103f46cb9). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:49:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:49:31 -0000 Subject: [GHC] #10050: template haskell Ppr missing parentheses for SigT In-Reply-To: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> References: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> Message-ID: <060.5a5e698a4ce9e6aa14e04695d6af21fe@haskell.org> #10050: template haskell Ppr missing parentheses for SigT -------------------------------------+------------------------------------- Reporter: aavogt | 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 thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via b5f465e247c37e905b25057aa9072c8861058381). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:49:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:49:42 -0000 Subject: [GHC] #10050: template haskell Ppr missing parentheses for SigT In-Reply-To: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> References: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> Message-ID: <060.162b78914e944fa6cdf74097c0021cec@haskell.org> #10050: template haskell Ppr missing parentheses for SigT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:50:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:50:08 -0000 Subject: [GHC] #10020: GHC 7.10 rejects nullary type class with associated data In-Reply-To: <050.7fe5de35678625902ef8dada7748ae56@haskell.org> References: <050.7fe5de35678625902ef8dada7748ae56@haskell.org> Message-ID: <065.d753cea30b2af560277aaa5bd5ec2424@haskell.org> #10020: GHC 7.10 rejects nullary type class with associated data -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: indexed- Blocked By: | types/should_compile/T10020 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged to `ghc-7.10` (via 4c8b65218c3ad4d040691453b60091b38a41a0b0). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:51:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:51:07 -0000 Subject: [GHC] #10036: Update Cabal before final 7.10 release In-Reply-To: <045.30bd56cc85f6bc5bb45606c0ed8642f0@haskell.org> References: <045.30bd56cc85f6bc5bb45606c0ed8642f0@haskell.org> Message-ID: <060.e5fdb8b37bff0b5cb3f9030df86b8030@haskell.org> #10036: Update Cabal before final 7.10 release -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc2 (other) | 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 thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Done; the `1.22` branch of Cabal was updated to include the patch, and `ghc-7.10` was updated in dd1561f7db43f8ee58af82670da463c562126379. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:53:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:53:21 -0000 Subject: [GHC] #9981: Potential typechecker regression in GHC 7.10.1RC In-Reply-To: <042.c047cab9d166b1747ff4913537189070@haskell.org> References: <042.c047cab9d166b1747ff4913537189070@haskell.org> Message-ID: <057.d6299484719e2bd929df5b6841965bcc@haskell.org> #9981: Potential typechecker regression in GHC 7.10.1RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | 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: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 Comment: Yes, agreed re: urgency. Moving out to 7.12 to clean things up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 09:58:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 09:58:46 -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.0f45f67b927411cb0af963ae40a1b698@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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 Comment: OK, so right now Ben Gamari and I are working on fixing up the LLVM backend in HEAD soon by shipping a known good version of LLVM for users to use; the new changes require LLVM 3.6 but seems to be stable on ARM and x86. So I'm punting this one out to 7.12 for now, since hopefully it will be fixed by using a fixed compiler with good test results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 10:01:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 10:01: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.bcd66e993a9ba4a330d942e18d982efc@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: new 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 erikd): The problem was that the `hsc2hs` code has a number of code blocks wrapped in: {{{ #if defined(mingw_HOST_OS) }}} and `mingw_HOST_OS` is defined when cross compiling from Linux/OSX to Windows. If I change the above to: {{{ #if (defined(mingw32_HOST_OS) && HostPlatform_TYPE == mingw32_HOST_OS) }}} the cross-compile process proceeds past this issue and runs into other issues later in the compile process. I don't have a Windows machine to test that this doesn't break MinGW native builds but the above certainly seems sensible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 10:04:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 10:04:28 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.87d9d91476681167b8aa18d42829a65d@haskell.org> #8406: Invalid object in isRetainer() or Segfault -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => infoneeded * milestone: 7.10.1 => 7.10.2 Comment: Can we still get a testcase if at all possible? As long as it has reproducible build instructions - without that, there's very little hope of us being able to do much here. FWIW, it looks unlikely this will make 7.10, so I'm moving out to a later milestone for a future bugfix release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 10:04:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 10:04:49 -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.ef3bbd411d4075e8325cc56a62cbcefb@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new 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: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.10.2 Comment: Simon says this is a real bug, but it's a corner case and a bit tricky to solve. So at the moment, I'm punting this one to a bugfix release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 10:06:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 10:06:23 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.6de68db594fd28d3b7c0373521e0c554@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 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 thoughtpolice): * milestone: 7.10.1 => 7.12.1 Comment: Looks like this one isn't changing in time for 7.10, so I'm moving it out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 10:14:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 10:14:53 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows with mising Win32 library Message-ID: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> #10070: Cross compiling from Linux to Windows with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: cross- | Type of failure: Building GHC compiling | failed Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After applying the proposed patch from #9524, building a Linux to Windows cross-compiler terminates with: {{{ Configuring time-1.5.0.1... ghc-cabal: At least the following dependencies are missing: Win32 -any }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 10:25:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 10:25:05 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.6d8ed42e5ea497ccaf3cdbca2de41c40@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 -------------------------------------+------------------------------------- Changes (by thomasw): * owner: => thomasw * differential: => Phab:D646 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 10:41:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 10:41:12 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows fails with mising Win32 library (was: Cross compiling from Linux to Windows with mising Win32 library) In-Reply-To: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> References: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> Message-ID: <059.55f87f5587f232b603e62c2e0b117e38@haskell.org> #10070: Cross compiling from Linux to Windows fails with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 11:04:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 11:04:16 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.0f17d63d4f5b432e93c196111dd1dfe4@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHCi crash | (amd64) Blocked By: | Test Case: Related Tickets: #7103, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): Replying to [comment:2 rwbarton]: Hello rwbarton! I'm working with both kdmadej as well as mmikolajczyk and this bug is some kind of blocker for us. I would love to ask you if can we discuss possible solutions / workarounds to make our use case work? We would like to collaborate with you guys as strong as we are able, we can try to investigate it further if you provide any hints for us - anything. As a side-note: we are using GHCi (or more strictly GHC API) under the hood and GHCi is some kind of interpreter our product bases on - because of that and because the release deadline is in very narrow time from now, we are worrying about that issue. I would be very thankful for any help! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 11:29:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 11:29:35 -0000 Subject: [GHC] #10071: Implement warnings for class-method overriding Message-ID: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> #10071: Implement warnings for class-method overriding -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: AMP | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #8004, #4384 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This would aid long-term transitions like phasing out `Monad(return)` (in the spirit of #4834): With the AMP, `Monad(return)` being a class method becomes an historic artifact. The ideal long-term situation would rather be to have `return` become a top-level definition (i.e. outside the `Monad`-class), generalised to `Applicative` just aliasing `Applicative(pure)`, i.e. {{{#!hs return :: Applicative f => a -> f a return = pure }}} This may be beneficial for things like ApplicativeDo which otherwise would require a `return` to be handled is if it was `pure` in order to weaken the type-constraint in an `do`-expression like e.g. {{{#!hs do { x <- f; return (fst x) } }}} Right now, we can attach a `DEPRECATE`-pragma to the `return`-class- method. That however would trigger warnings on ''all'' uses of `return`, rather than only when using `return` in a context that requires it to be a class-method (like overriding `return` in instance definitions, or importing/exporting it via the explicit `Monad(return)`-syntax) Instead we need a way to warn about such uses of `return` which assume it to be a class-method, in order to phase out such uses. NB: This will probably require additional discussions, but we shouldn't wait too long, if we want to integrate the AMP into a future Haskell Report (for which we should try to clean up historic warts such as `Monad(return)` if feasable). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 12:06:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 12:06:06 -0000 Subject: [GHC] #7103: Compiler panic, when loading wxc in GHCi In-Reply-To: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> References: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> Message-ID: <062.747a12eac9ff081fc35abff26697de58@haskell.org> #7103: Compiler panic, when loading wxc in GHCi -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: 3658 | Test Case: Related Tickets: #9907, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darthdeus): I ran into the same thing while trying to get the `mysql` package working, where after many changes I was able to get the package to successfully compile on its own, but while linking with a larger application this error essentially killed the deployment, since there doesn't seem to be a way to work around it. Removing the idata$4 section with `--no-idata4` yielded the same error with idata$5, so we tried removing that with `--no-idata5`, but then ran into the same issue with idata$7. ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: Unknown PEi386 section name `.idata$7' (while processing: C:\Haskell\ert\.cabal-sandbox\x86_64-windows- 7\libmysql.a) cabal: Error: some packages failed to install: We also tried modifying dlltool to remove the idata$7 section as well (source https://sourceware.org/git/?p=binutils.git;a=blob;f=binutils/dlltool.c), but without any success. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 12:16:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 12:16:49 -0000 Subject: [GHC] #10071: Implement warnings for class-method overriding In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.4d17049126196ce0e67bb2df420722cc@haskell.org> #10071: Implement warnings for class-method overriding -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8004, #4384 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): What on earth is this ticket about? The first word is "This", presumably referring to something, but with no clue about ''what'' it is referring to. I am utterly lost. A feature request (which I assume this is) needs a specification! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 12:45:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 12:45:25 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.30efdfad693937c322a1212d74f9f5c7@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 maoe): * cc: maoe@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 13:19:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 13:19:15 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.4013de803516490974a1820d101356a6@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Prelude | 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 yalas): Replying to [comment:36 thomie]: > Because it broke validate, see comment:33. Can I do something to fix it? And why did it brake validate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 13:22:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 13:22:10 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions (was: Implement warnings for class-method overriding) In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.f4a6a39a60dfbe03f048b97d52dac995@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8004, #4384 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > This would aid long-term transitions like phasing out `Monad(return)` (in > the spirit of #4834): > > With the AMP, `Monad(return)` being a class method becomes an historic > artifact. The ideal long-term situation would rather be to have `return` > become a top-level definition (i.e. outside the `Monad`-class), > generalised to `Applicative` just aliasing `Applicative(pure)`, i.e. > > {{{#!hs > return :: Applicative f => a -> f a > return = pure > }}} > > This may be beneficial for things like ApplicativeDo which otherwise > would require a `return` to be handled is if it was `pure` in order to > weaken the type-constraint in an `do`-expression like e.g. > > {{{#!hs > do { x <- f; return (fst x) } > }}} > > Right now, we can attach a `DEPRECATE`-pragma to the `return`-class- > method. That however would trigger warnings on ''all'' uses of `return`, > rather than only when using `return` in a context that requires it to be > a class-method (like overriding `return` in instance definitions, or > importing/exporting it via the explicit `Monad(return)`-syntax) > > Instead we need a way to warn about such uses of `return` which assume it > to be a class-method, in order to phase out such uses. > > NB: This will probably require additional discussions, but we shouldn't > wait too long, if we want to integrate the AMP into a future Haskell > Report (for which we should try to clean up historic warts such as > `Monad(return)` if feasable). New description: == What? Implement a `DEPRECATED`-variant to be attached to method declarations (in `class`-definitions) with default implementations that triggers warnings when 1. When an `instance` overrides the default implementation of that method, and/or 2. when such a deprecated method is explicitly im/(re)exported via `Class(method)`-syntax. But not when 1. imported as e.g. `import Mod1 (Class, method)` (which doesn't require `method` to be a method of `Class`), nor when 2. merely referring to `method` in an expression (as that doesn't require `method` to be a method either). Syntax suggestion: {{{ class C a where foo :: a bar :: a -> a bar x = x doo :: a -- this is the new syntax {-# DEPRECATED C(bar) "'bar' is going to become a non-method soon, please avoid referring to it as a method" #-} -- this works already now {-# DEPRECATED foo "'foo' is obsolete and going away soon, please use 'doo' instead" #-} }}} == Why? This would aid long-term transitions like phasing out class-methods, such as e.g. `Monad(return)` in the spirit of #4834: With the AMP, `Monad(return)` being a class method becomes an historic artifact. The ideal long-term situation would rather be to have `return` become a top-level definition (i.e. outside the `Monad`-class), generalised to `Applicative` just aliasing `Applicative(pure)`, i.e. {{{#!hs return :: Applicative f => a -> f a return = pure }}} This may be beneficial for things like ApplicativeDo which otherwise would require a `return` to be handled is if it was `pure` in order to weaken the type-constraint in an `do`-expression like e.g. {{{#!hs do { x <- f; return (fst x) } }}} Right now, we can attach a `DEPRECATED`-pragma to the `return`-class- method. That however would trigger warnings on ''all'' uses of `return`, rather than only when using `return` in a context that requires it to be a class-method (like overriding `return` in instance definitions, or importing/exporting it via the explicit `Monad(return)`-syntax) Instead we need a way to warn about such uses of `return` which assume it to be a class-method, in order to phase out such uses. NB: This will probably require additional discussions, but we shouldn't wait too long, if we want to integrate the AMP into a future Haskell Report (for which we should try to clean up historic warts such as `Monad(return)` if feasable). -- Comment (by hvr): I hope this makes it more clear what I'm proposing. When I started writing the ticket I wasn't sure if I wanted a general facility, or something more adhoc for the specific AMP use-case, and so ended up with the incomplete description... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 13:30:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 13:30:17 -0000 Subject: [GHC] #10072: Panic: generalised wildcards in RULES Message-ID: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> #10072: Panic: generalised wildcards in RULES -------------------------------------+------------------------------------- Reporter: thomasw | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: | crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Generalised wildcards (PartialTypeSignatures) in the binder type annotation of a RULE cause panics. Minimal example: {{{#!hs module WildcardInRuleBndrSig where {-# RULES "map/empty" forall (f :: a -> _). map f [] = [] #-} }}} Output: {{{ WildcardInRuleBndrSig.hs:3:31:ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.11.20150209 for x86_64-unknown-linux): No skolem info: w__alY[sk] }}} When a wildcard is generalised over, the error message reporting the inferred type gives some extra info about the type variables occurring in the inferred type. This extra information is retrieved by looking up the skolem information (`getSkolemInfo`) for the type variables in the enclosing implications (`cec_encl`). The problem is that there are no enclosing implications in this case, hence the panic. Note that with the flags `-XPartialTypeSignatures` and `-fno-warn-partial- type-signatures` enabled, there is no panic, as no error/warning message is constructed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 13:34:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 13:34:01 -0000 Subject: [GHC] #10072: Panic: generalised wildcards in RULES In-Reply-To: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> References: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> Message-ID: <061.dc68876e16790628cf56098c5f9d6639@haskell.org> #10072: Panic: generalised wildcards in RULES -------------------------------------+------------------------------------- Reporter: thomasw | Owner: thomasw Type: bug | 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: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by thomasw): Bug discovered while working on Phab:D613, where I also proposed an unsatisfactory stopgap solution: not printing extra skolem information when there is none. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 13:49:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 13:49:37 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.8e05812a9d1d72072ef763286c027b01@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8004, #4384 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Better. Syntax: why not just do this for a nested DEPRECATED pragma, thus {{{ class C a where foo :: a bar :: a -> a bar x = x {-# DEPRECATED bar "burble wurble" #-} doo :: a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 13:56:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 13:56:02 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.e9dbdc11ca36c0b0b7dcd0aa5229cee2@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8004, #4384 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:3 simonpj]: > Better. Syntax: why not just do this for a nested DEPRECATED pragma, thus Works too (I'm only slightly worried that it might be confusing for users that the indentation-level of the `{-# DEPRECATED #-}` changes its semantics, but I have no strong preference here) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 15:29:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 15:29:25 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.06524a6358ea85321fbeca8aa859858c@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: -------------------------------------+------------------------------------- Comment (by simonpj): For me `fa` and `fb` generate identical code. Are you sure about those NOINLINE pragmas? Maybe give the command line you use for compiling, and show the output of `-ddump-simpl`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 15:32:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 15:32:25 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.b51d856eed05b3ef4fd571d672c33716@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHCi crash | (amd64) Blocked By: | Test Case: Related Tickets: #7103, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): > I would love to ask you if can we discuss possible solutions / workarounds to make our use case work? Use Linux? :) Sorry, I have no Windows experience and no access to a Windows machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 15:46:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 15:46:20 -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.4748cdb72544cdebcde953a63c72ce1d@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: new 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 rwbarton): Oh, I was going to batch this with some other hsc2hs fixes, and then I got sidetracked. I think the fix of simply removing the `#include "../../includes/ghcconfig.h"` is better though. #including that file in a Haskell program is risky business, since the `foo_HOST_OS` CPP symbol it defines is in the same namespace as the `bar_HOST_OS` CPP symbol that is automatically defined by any run of GHC. For example, in the case under discussion here, both `linux_HOST_OS` and `mingw_HOST_OS` are defined since hsc2hs is being built with the bootstrap compiler. There should be no need for hsc2hs to know about the eventual target machine type, only the machine type that it is being built to run on. Or in other words, it is sensible to build hsc2hs independently of the GHC build process. So, let's just remove that #include to ensure that we only get the right versions of the `foo_HOST_OS` symbols, the ones that come from whatever GHC is building hsc2hs, and which are correct for the machine hsc2hs is to run on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 16:07:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 16:07:53 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.d8c4bc2607e15721120e5da14f294f26@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.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 asr): * status: new => closed * resolution: => invalid Comment: cpphs 1.18.8 doesn't handle the `#if defined` syntax, so it isn't a GHC bug. I'll report the issue to cpphs' author. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 16:29:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 16:29:35 -0000 Subject: [GHC] #10072: Panic: generalised wildcards in RULES In-Reply-To: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> References: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> Message-ID: <061.5106cad2db92a7a15387c1545d55f784@haskell.org> #10072: Panic: generalised wildcards in RULES -------------------------------------+------------------------------------- Reporter: thomasw | Owner: thomasw Type: bug | 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: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): We should never generalise over wildcards! Thomas, are you ok to look into this one? Yell if you need help. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 16:44:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 16:44:32 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.38bf3f747820deacae51220cf0e01bbe@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 simonpj): I would love someone to take this on. It's detail work, but treating `(~)` more systematically would be a jolly good thing, and a public service. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 16:56:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 16:56:29 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.87841e6c9df00152ba11ba1c2bde2ece@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Prelude | 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 ekmett): Hacking up your patch to change the shadowing `x` and two shadowing `y`s should do it. e.g. {{{ + ((re:+im), y) + | (isInfinite re || isInfinite im) -> case y of - ((re:+im), y') - | (isInfinite re || isInfinite im) -> case y' of - (x, y) -> exp (log x * y) + (x', y') -> exp (log x' * y') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 17:19:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 17:19:29 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.91939ca981132f0556de4c64b48f78e3@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8004, #4384 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): The main purpose of such a feature is to give us the ability to smoothly remove redundant class members over a deprecation cycle. (Admittedly, perhaps, quite a long deprecation cycle in the case of something like `return`!) e.g. `(>>)` could be reduced to a top level binding to `(*>)` after a period with a warning making it clear that this was coming. Other examples of candidates are Traversable's `sequence` and `sequenceA`, although there is currently a technical barrier to removing `mapM` entirely. This would enable us to eventually reclaim `sequence` for use on `Applicative` data types. Having the ability to do these things means we can put together future proposals for how to move AMP (or FTP) along with reduced breakage. I confess to not being terribly concerned about the choice of syntax, though. =) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 19:49:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 19:49:47 -0000 Subject: [GHC] #10073: Idris REPL is pretty and we can too Message-ID: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> #10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: feature | Status: new request | 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: | -------------------------------------+------------------------------------- Manual for configuring colors in the Idris REPL: https://github.com/idris- lang/Idris-dev/wiki/Manual#colours Screenshot: http://i.imgur.com/rYHCI4T.png Particularly, I'd like to make type errors and warnings more visually distinct. I think little touches like this can go a long way to making it nice to work with Haskell code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 20:07:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 20:07:26 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.ec1c7e0600d845dcab6a37b6994ef4eb@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Comment (by George): Given the ongoing discussion in e.g. the Libraries mailing list should the status still be closed? Are all the proposed changes in 7.10RC2? If so when will the 7.10 doc be updated to reflect them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 20:24:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 20:24:06 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.d5b50f7d683a84af2b005fe2be6a3f3a@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Changes (by George): * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 20:35:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 20:35:39 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.c16d8255e47cf35e096df16067c98464@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Comment (by ekmett): We are currently constructing a poll and summaries of two possible plans of action that will go out in the next day or so. Based on the results of that poll, which will likely run until the 28th or so, to give folks a couple of weeks to respond, Simon Peyton Jones and Simon Marlow will come to a decision on how we are going to proceed for 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 21:16:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 21:16:14 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal Message-ID: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice thoughtpolice | Status: new Type: task | Milestone: 7.12.1 Priority: high | Version: Component: Compiler | Operating System: Unknown/Multiple (LLVM) | Type of failure: None/Unknown Keywords: llvm, | Blocked By: codegen | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: Phab:D530 | -------------------------------------+------------------------------------- This is a meta ticket designed to reflect the current implementation status of the 'Improved LLVM Backend' proposal, documented here: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 21:24:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 21:24:31 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.f81be19fe61ad1bee73c58daac6b9ce4@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:36 George]: > If so when will the 7.10 doc be updated to reflect them? Which part of the documentation are you referring to, btw? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 21:33:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 21:33:35 -0000 Subject: [GHC] #10073: Idris REPL is pretty and we can too In-Reply-To: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> References: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> Message-ID: <063.e5c39586d068ed408d91a8c30f117750@haskell.org> #10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Related: https://wiki.haskell.org/GHCi_in_colour For the meantime, until GHCi gains native support for colours, the Emacs `haskell-mode` provides a coloured REPL with the ability to jump to referenced source-locations... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 21:38:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 21:38:08 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.dae4046a7c844b40cde2a061246163cf@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Comment (by George): Thanks but I don't see an answer to my questions: 1) Should the status of this ticket still be closed? This issue doesn't show on https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 but the issue still appears to be open thus the referenced Status page doesn't give an indication of the true status of the release 2) Are all the proposed changes in 7.10RC2? wrt doc I am referring to the GHC User's Guide and Hackage documentation such as https://hackage.haskell.org/package/base-4.7.0.2/docs/Data- List.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 21:49:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 21:49:02 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.6dc9e9b52d5e7c4fe4b9e38ebe9b35ac@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: -------------------------------------+------------------------------------- Comment (by pacak): Those NOINLINE pragmas are required to replicate the behavior I'm getting in the production code. Generated core looks the same, generated assembly code is different though. With more fields added (see attachment) performance difference is 4x, goes away as soon as I get rid of forall'ed field. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 21:54:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 21:54:36 -0000 Subject: [GHC] #10073: Idris REPL is pretty and we can too In-Reply-To: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> References: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> Message-ID: <063.9f56f43537e3ba315c846ba3a358ded6@haskell.org> #10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bitemyapp): @hvr - I'm a user of haskell-mode and haskell-interactive-mode, the colouring is nice, but the source-loc jumping hasn't ever worked for me. That only worked in ghci-ng, and even then, not reliably. Sometimes, for various reasons, I can't use h-i-m and must use cabal repl in the terminal. When that happens, and for the benefit of non-Emacs users, I'd like it to be pretty :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 9 22:22:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Feb 2015 22:22:37 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.096950fad57a4480c21c595ba4e5ee07@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: -------------------------------------+------------------------------------- Comment (by pacak): It's compiled with ghc -O2 bench.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 04:42:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 04:42:52 -0000 Subject: [GHC] #10075: Muddling Constraint and * means that Core is inconsistent Message-ID: <047.b702f44c1941de44349c325db22c80fd@haskell.org> #10075: Muddling Constraint and * means that Core is inconsistent -------------------------------------+------------------------------------- Reporter: goldfire | 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: | -------------------------------------+------------------------------------- I can say this: {{{ type family F (a :: k) type instance F (a :: Constraint) = Int type instance F (a :: *) = Bool }}} This compiles to the following Core: {{{ F :: forall (k :: BOX). k -> * axF1 :: [a :: Constraint].F Constraint a ~ Int axF2 :: [a :: *]. F * a ~ Bool }}} I can then build the following: {{{ sym axF1[Any Constraint] ; axF2[Any *] :: Int ~ Bool }}} The transitivity is sound because, in Core, `Constraint` and `*` are indistinguishable. I don't think there's a way to actually cause a bug in a running program due to this problem, but we should probably patch it up. Possible resolution: Have `coreView` change `Constraint` to `*`. Possible resolution once we have `* :: *`: Make `Constraint` and `*` representationally equal. In other words, it would be as if `Constraint` were a newtype around `*`. I haven't thought out the ramifications of this decision, but there's something nice about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 08:18:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 08:18:03 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.8cf8ef4acfeaf32f24a1b319d4a0be24@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Prelude | 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 lukyanov): Replying to [comment:39 ekmett]: > Hacking up your patch to change the shadowing `x` and two shadowing `y`s should do it. e.g. > > {{{ > - ((re:+im), y) > - | (isInfinite re || isInfinite im) -> case y of > + ((re:+im), y') > + | (isInfinite re || isInfinite im) -> case y' of > > - (x, y) -> exp (log x * y) > + (x', y') -> exp (log x' * y') > }}} Or just without duplicating them: {{{ - ((re:+im), y) + ((re:+im), _) - (x, y) -> exp (log x * y) + _ -> exp (log x * y) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 08:34:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 08:34:55 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.1a905f63ef443da7113c8d46b137645f@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Prelude | 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 lukyanov): And we can simplify it a bit: {{{ x ** y = case (x,y) of (_ , (0:+0)) -> 1 :+ 0 ((0:+0), (exp_re:+_)) -> case compare exp_re 0 of GT -> 0 :+ 0 LT -> inf :+ 0 EQ -> nan :+ nan ((re:+im), (exp_re:+_)) | (isInfinite re || isInfinite im) -> case compare exp_re 0 of GT -> inf :+ 0 LT -> 0 :+ 0 EQ -> nan :+ nan | otherwise -> exp (log x * y) where inf = 1/0 nan = 0/0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 08:46:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 08:46:40 -0000 Subject: [GHC] #10075: Muddling Constraint and * means that Core is inconsistent In-Reply-To: <047.b702f44c1941de44349c325db22c80fd@haskell.org> References: <047.b702f44c1941de44349c325db22c80fd@haskell.org> Message-ID: <062.3138741a849a703050fac28db7f45e12@haskell.org> #10075: Muddling Constraint and * means that Core is inconsistent -------------------------------------+------------------------------------- Reporter: goldfire | 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): Ha! Good point! I like your newtype idea. I don't understand the `coreView` idea. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 09:34:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 09:34:21 -0000 Subject: [GHC] #10072: Panic: generalised wildcards in RULES In-Reply-To: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> References: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> Message-ID: <061.2d8afa0cd6aeaa52eca8b05ec6e3ac9e@haskell.org> #10072: Panic: generalised wildcards in RULES -------------------------------------+------------------------------------- Reporter: thomasw | Owner: thomasw Type: bug | 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: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by thomasw): Replying to [comment:2 simonpj]: > We should never generalise over wildcards! I'm confused, we do generalise over wildcards when possible, right? When I say "the wildcard is generalised over", I mean that when the wildcard is not instantiated to a monotype, we replace it with a fresh type variable and universally quantify it. This is what we have being doing the whole time, e.g.: {{{#!hs foo :: _ -> _ foo x = x -- Inferred: w_ -> w_ }}} What I expected in the example in the description above (and what indeed happens) is that the wildcard is generalised over and that we get `a -> w_` as type for `f`. > Thomas, are you ok to look into this one? Yell if you need help. I see two ways to solve it: 1. Don't print skolem information when there is none (easy). 2. Generate an `Implication` with the right skolem information (harder). Which solution do you prefer? If you prefer 2, I'd appreciate some pointers as to where/when these `Implication` constraints should be generated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 09:39:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 09:39:08 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.b835c24ec88162be3e5312af34ae6081@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: -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for the `-ddump-simpl` output. I can see what is happening. The trouble is that `a1`, `a2` etc are marked `NOINLINE`, but their strictness information is still visible. That makes `fa` strict too. So the original code looks like this (I have decreased the number of selectors to make it easy to read): {{{ --------- Before strictness analysis ------------- fa a = case a1 a of I# i1 -> case a2 a of I# i2 -> I# (i1 +# i2) --------- After strictness analysis and worker/wrapper ------------- fa a = case a of A _ _ _ _ i1 _ _ _ _ i2 _ _ _ _ -> $wfa i1 i2 $wfa i1 i2 = let a = A bot bot bot bot i1 bot bot bot bot i2 bot bot bot bot in case a1 a of I# i1 -> case a2 a of I# i2 -> I# (i1 +# i2) }}} The worker `$wfa` would normally collapse into nice tight code, when the workers for `a1` and `a2` are inlined. But here they are not! So `$wfa` does reboxing which is terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 09:51:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 09:51:43 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.95f4d00888e1a7c79cc55c7351189e41@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: -------------------------------------+------------------------------------- Comment (by pacak): There are no NOINLINE in code we are using in production but behavior is similar - works faster with unused field with ExistentialQuantification. So it disables not only CPR but some other optimizations as well. What's the conclusion then? Is that fixable or I need to look for other examples? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 09:59:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 09:59:47 -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.320fd4434618156a76f4a51fe599fd93@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: new 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): I'm stuck at a Cabal error message: {{{ peter at montebre:~/projects/haskell/singletons> cabal install --only- dependencies Resolving dependencies... Downloading syb-0.4.4... Downloading th-lift-0.7... Configuring th-lift-0.7... Configuring syb-0.4.4... cabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf }}} This is a fresh build of ghc-7.10-rc2 and cabal-install 1.22.0.0. {{{ peter at montebre:~/projects/haskell/singletons> ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.0.20150123 peter at montebre:~/projects/haskell/singletons> cabal --version cabal-install version 1.22.0.0 using version 1.22.1.0 of the Cabal library }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 10:13:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 10:13:12 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.fd4c595ba3a7627931bd58a66a33191d@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: -------------------------------------+------------------------------------- Comment (by simonpj): That's odd. I don't understand how that is happening. I need more information. Can you show a `-ddump-simpl` of the bit of your production code that is allocating more? (With and without the change.) If you compile with `-ticky` and then run with `+RTS -rfoo.ticky` the file `foo.ticky` will show which function is allocating how much. If you compare with and without the existential change you should see an obvious culprit. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 10:26:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 10:26:22 -0000 Subject: [GHC] #9094: remove RAW_CPP In-Reply-To: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> References: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> Message-ID: <060.3ddd632e01568eab95f878ddcd5b3504@haskell.org> #9094: remove RAW_CPP -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 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: #8683 | Blocking: | Differential Revisions: Phab:D648 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D648 * blockedby: 8683 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 10:30:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 10:30:31 -0000 Subject: [GHC] #10076: Don't suppress warnings in the presence of errors Message-ID: <048.07984c34d4e400833c1a386400621378@haskell.org> #10076: Don't suppress warnings in the presence of errors -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: | warning at compile-time Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this fragment of code (uses injective type families, not yet merged into HEAD): {{{#!hs type family Bar a = r | r -> a where Bar Int = Bool Bar Bool = Int Bar Bool = Char bar :: Bar a -> Bar a bar x = x barapp :: Char barapp = bar 'c' }}} GHC rejects this with an error: {{{ Couldn't match expected type ?Bar a0? with actual type ?Char? The type variable ?a0? is ambiguous In the first argument of ?bar?, namely ?'c'? In the expression: bar 'c' In an equation for ?barapp?: barapp = bar 'c' }}} The reason why this is rejected is that the last type family equation is not reachable. GHC warns about that if I comment out `barapp`: {{{ Dropping overlapped type family instance equation: Bar Bool = Char }}} I believe that with that warning source of the error would be easier to find. So I propose that by default GHC does not suppress warnings in the presence of errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 10:32:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 10:32:43 -0000 Subject: [GHC] #1103: Japanese Unicode In-Reply-To: <047.1b624b52c8e7f3189b55a2a1d4184482@haskell.org> References: <047.1b624b52c8e7f3189b55a2a1d4184482@haskell.org> Message-ID: <062.b5a9cf397510b34693576ae606b9ad53@haskell.org> #1103: Japanese Unicode -------------------------------------+------------------------------------- Reporter: humasect | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 Component: Compiler | branch (Parser) | Version: 6.6 Resolution: fixed | Keywords: japanese Operating System: Unknown/Multiple | unicode lexical -fglasgow-exts Type of failure: None/Unknown | report-impact Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * keywords: japanese unicode lexical -fglasgow-exts => japanese unicode lexical -fglasgow-exts report-impact * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 10:36:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 10:36:27 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error Message-ID: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Linux Keywords: | Type of failure: Incorrect typechecker plugin cycle imports | warning at compile-time Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I am playing around with the new type checker plugins using the current development branch of GHC. When I supply the plugin module to GHC through the command line I get a cyclic import error message, which I think is false. If I supply the same plugin module using a pragma I do not get an error message. === Minimal Example (Command Line) `MyPlugin.hs`: {{{#!hs module MyPlugin ( plugin ) where import Plugins ( Plugin, defaultPlugin ) plugin :: Plugin plugin = defaultPlugin }}} `Test.hs`: {{{#!hs module Test where main :: IO () main = return () }}} Command line call of GHC: {{{ ~/ghc/inplace/bin/ghc-stage2 \ --make -package ghc-7.11.20150209 \ -fplugin=MyPlugin \ Test.hs }}} Results in the following error {{{ Module imports form a cycle: module ?MyPlugin? (./MyPlugin.hs) imports itself }}} which does not seem reasonable to me understand. === Minimal example (pragma) On the other hand, if I change `Test.hs` to the following {{{#!hs {-# OPTIONS_GHC -fplugin MyPlugin #-} module Test where main :: IO () main = return () }}} and calling GHC like this {{{ ~/ghc/inplace/bin/ghc-stage2 \ --make \ -package ghc-7.11.20150209 \ -dynamic \ Test.hs }}} it works. I did not change `MyPlugin.hs`. === Note 1. Using `-fplugin=MyPlugin` vs. `-fplugin MyPlugin` does not make a difference. 1. The command line example behaves the same independent of whether I supply the `-dynamic` flag or not. 1. I had to add the `-dynamic` flag, because otherwise GHC will complain that: {{{ : cannot find normal object file ?./MyPlugin.dyn_o? while linking an interpreted expression }}} This might be a long shot, but maybe using the `-fplugin` option should imply the `-dynamic` flag? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 10:45:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 10:45:21 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.f208b1e69a3de80e7e4cd09e7dcba721@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Prelude | 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 ekmett): Even better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 10:50:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 10:50:49 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error In-Reply-To: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> References: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> Message-ID: <062.ac44761151a84e70cb6758b67fe8d372@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | typechecker plugin cycle imports Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jbracker): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 11:11:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 11:11:50 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.ad235bbd93e7d36be1d91d83bd740e7f@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: -------------------------------------+------------------------------------- Comment (by pacak): Found a file, it contains -fno-spec-constr on top, a comment to that key: -- this was added because it makes compilation blow up with ghc-7.8.3, and -- sims were neutral. -- Consider removing after ghc is fixed. It contains relatively simple Parser parser and a bunch of functions modifying a huge data structure - different fields in this structure. 507572 1368414112 0 313 >MSMLSSSSSSLLMMSDDDD XXXXXXX-0.1.0.0:XXXXXXX.$wa{v rbsKm} With removed -fno-spec-constr it takes forever to compile (30 minutes already, that's 700 lines of code). Trying to pick relevant bits of core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 11:13:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 11:13:12 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.4147643f823010bfc1299f0dc9304a2f@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: -------------------------------------+------------------------------------- Comment (by simonpj): Leave the `-fno-spec-constr`. Let's change only one thing at a time. Does it happen with `-O` or only with `-O2`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 11:19:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 11:19: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.02a98bf02260db30a032c143edb5f49c@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 -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > I think it would be a great idea for Core Lint to check for uses of > `unsafeCoerce` that don't obey the rules. It won't catch all cases, of > course, but it would have caught #9035. Specficially, look for: > * Coercions between lifted and unboxed types > * Coercion between unboxed types of different sizes > * Coercion between unboxed ints and floats. > > Would anyone like to make a patch for this? Anything that can be checked > by Core Lint, should be checked! > > I'm afraid I don't know where to look for the reason for the int/float > difficulty. I'd write a tiny function that exhibits the unsafe > conversion and look the code it generates. > > Simon New description: I think it would be a great idea for Core Lint to check for uses of `unsafeCoerce` that don't obey the rules. It won't catch all cases, of course, but it would have caught #9035. Specficially, look for: * Coercions between lifted and unboxed types * Coercion between unboxed types of different sizes * Coercion between unboxed ints and floats. Would anyone like to make a patch for this? Anything that can be checked by Core Lint, should be checked! I'm afraid I don't know where to look for the reason for the int/float difficulty. I'd write a tiny function that exhibits the unsafe conversion and look the code it generates. Wiki design page [wiki:BadUnsafeCoercions] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 11:35:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 11:35:12 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.518acc45c3008b9a6222e7ca21adf3eb@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: -------------------------------------+------------------------------------- Comment (by pacak): With -O $wa is still there and looks about the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 11:39:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 11:39:35 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.d751e43c4218de9653979d8ce6fab91e@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: -------------------------------------+------------------------------------- Comment (by pacak): And performance also suffers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 11:49:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 11:49:08 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.139aa68d1f76db54fa8b39e9fcb66930@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: -------------------------------------+------------------------------------- Comment (by simonpj): Like I say in comment:8, I can't help without more info. Can you give a `-ddump-simpl` of code that shows the problem without use of NOINLINE? Maybe your production code. I understand why it happens with NOINLINE (comment:6). But you say you don't use it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 11:52:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 11:52:06 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.25a79ead80d9fda44a17d2ea8df9b927@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: -------------------------------------+------------------------------------- Comment (by pacak): 22k lines, trying to pick relevant bits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 12:02:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 12:02:43 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.14b1d0e7578b43410249c3081a80072f@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: -------------------------------------+------------------------------------- Comment (by pacak): Simon, can I send you an email? Core is 1.3Mb so I can't attach it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 12:05:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 12:05:43 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error In-Reply-To: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> References: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> Message-ID: <062.553bd5dabdeace7f431ebe8df9323342@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | typechecker plugin cycle imports Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): This is arguably correct behaviour, though I agree that it's less than ideal. The combination of `--make` and `-fplugin` is often troublesome, because `-fplugin MyPlugin` essentially imports `MyPlugin` in every module being compiled. (As usual, when you do `ghc --make Test.hs` the dependencies of `Test.hs` are compiled with the same command-line flags ``.) Thus your first example ends up compiling `MyPlugin` with `-fplugin MyPlugin`, which is obviously cyclic. If you're defining and using a plugin in a single package, I recommend using `OPTIONS_GHC` pragmas in the modules that rely on the plugin, rather than supplying `-fplugin` on the command line. As you've discovered, this avoids the problem. Alternatively, you can define the plugin in one package and use it in another, then it is easy to compile the first package without `-fplugin`, and you can use it globally in the second package. I guess we should make the documentation clearer about how to avoid this problem, and perhaps change the cyclic import message to be more informative in the presence of plugins. Regarding `-dynamic`, I guess we should do something similar to #8180, since it's basically the same issue: if you use `-fplugin MyPlugin` anywhere in the module graph, the compilation manager should make sure that `MyPlugin` is compiled with `-dynamic` or `-dynamic-too`. I don't know how tricky this would be to implement, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 12:08:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 12:08:45 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.b1d10f7a7232a93c73db8d84d32b6ff2@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: -------------------------------------+------------------------------------- Comment (by pacak): $wa takes half of the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 12:18:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 12:18:47 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error In-Reply-To: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> References: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> Message-ID: <062.3f06dd1e6a9987ca8574ceb3d84fc28f@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | typechecker plugin cycle imports Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): I've added a [wiki:Plugins/TypeChecker#FAQ section to the typechecker plugins wiki page] documenting these issues. Suggestions for improvement are welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 12:25:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 12:25:59 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.0a84bb405f7bac57985d1c486806a5e3@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: -------------------------------------+------------------------------------- Comment (by simonpj): send email if you like, yes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 13:03:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 13:03:31 -0000 Subject: [GHC] #10075: Muddling Constraint and * means that Core is inconsistent In-Reply-To: <047.b702f44c1941de44349c325db22c80fd@haskell.org> References: <047.b702f44c1941de44349c325db22c80fd@haskell.org> Message-ID: <062.4b8bd8051be81b072e2ce07bdd7b12d7@haskell.org> #10075: Muddling Constraint and * means that Core is inconsistent -------------------------------------+------------------------------------- Reporter: goldfire | 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 running `coreView` -- the function that unwraps type synonyms before inspecting a type -- also returned `Just *` when given `Constraint`, I think the problem would be solved. This essentially treats `Constraint` as a type synonym for `*` in `coreView`, but not in `tcView`. On the other hand, if we implemented this `coreView` idea, then my example code wouldn't compile, as the type instances would overlap. From a Haskell (as opposed to Core) point of view, the overlap here would be strange, as `Constraint` and `*` ''are'' distinct in Haskell. Perhaps we really do need kind equalities to sort this one out... :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 13:07:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 13:07:25 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error In-Reply-To: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> References: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> Message-ID: <062.c4ff2ee6d8d7f8c1cb2e19576f40e2ba@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | typechecker plugin cycle imports Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jbracker): Replying to [comment:2 adamgundry]: > This is arguably correct behaviour, though I agree that it's less than ideal. The combination of `--make` and `-fplugin` is often troublesome, because `-fplugin MyPlugin` essentially imports `MyPlugin` in every module being compiled. I have trouble understanding why a plugin needs to be imported to the module that uses it. As far as I understand GHC dynamically loads the plugin module and uses it, but I don't see why the plugin needs to be imported to the compiled module, since the modules do not have access to the plugins functionality anyway. Is this required because the plugin might import other modules in scope? > I guess we should make the documentation clearer about how to avoid this problem, and perhaps change the cyclic import message to be more informative in the presence of plugins. Yes, I agree. Thank you for extending the wiki page! > Regarding `-dynamic`, I guess we should do something similar to #8180, since it's basically the same issue: if you use `-fplugin MyPlugin` anywhere in the module graph, the compilation manager should make sure that `MyPlugin` is compiled with `-dynamic` or `-dynamic-too`. I don't know how tricky this would be to implement, though. Looking at the changes from that ticket it does not seem to be too much work: [changeset:"e25af05656b496b997c8f3520e5ac8e377a68e7b/ghc"] Though there might be lingering problems arising from this. Replying to [comment:3 adamgundry]: > I've added a [wiki:Plugins/TypeChecker#FAQ section to the typechecker plugins wiki page] documenting these issues. Suggestions for improvement are welcome! Maybe a link to this ticket, in case someone wants to know more about the issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 13:58:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 13:58:10 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error In-Reply-To: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> References: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> Message-ID: <062.c0093e15d2b31e71649ec1ea0d4628e9@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | typechecker plugin cycle imports Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): Replying to [comment:4 jbracker]: > Replying to [comment:2 adamgundry]: > > This is arguably correct behaviour, though I agree that it's less than ideal. The combination of `--make` and `-fplugin` is often troublesome, because `-fplugin MyPlugin` essentially imports `MyPlugin` in every module being compiled. > > I have trouble understanding why a plugin needs to be imported to the module that uses it. As far as I understand GHC dynamically loads the plugin module and uses it, but I don't see why the plugin needs to be imported to the compiled module, since the modules do not have access to the plugins functionality anyway. Is this required because the plugin might import other modules in scope? Or is there some other technical reason? To try to clarify: it's not exactly true that the plugin needs to be **imported** into a module that uses it, although I believe the implementation works more-or-less like that, with some cleverness to avoid e.g. typeclass instances being brought in. The point is that if module `M` uses a plugin in module `P`, then we have to dynamically load `P` in order to typecheck `M`. Hence `P` cannot depend (directly or indirectly) on `M`! When `-fplugin=P` is used on the command-line, GHC tries to load `P` for every module being compiled, which might include `P` itself. This isn't exactly a cyclic import, but it's pretty close. > > I've added a [wiki:Plugins/TypeChecker#FAQ section to the typechecker plugins wiki page] documenting these issues. Suggestions for improvement are welcome! > > Maybe a link to this ticket, in case someone wants to know more about the issue? Yes. Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 14:01:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 14:01:36 -0000 Subject: [GHC] #9986: lhs -> hs fallout In-Reply-To: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> References: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> Message-ID: <063.1271cf8f9f7259b5592390d2624de07c@haskell.org> #9986: lhs -> hs fallout -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | thoughtpolice Priority: normal | Status: patch Component: Documentation | Milestone: Resolution: | Version: 7.9 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: D621 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"83efb985d632d3a351f69cb6ce9dc5232127d545/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="83efb985d632d3a351f69cb6ce9dc5232127d545" Replace .lhs with .hs in compiler comments Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that. Reviewers: austin, jstolarek, hvr, goldfire Reviewed By: austin, jstolarek Subscribers: thomie, goldfire Differential Revision: https://phabricator.haskell.org/D621 GHC Trac Issues: #9986 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 14:01:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 14:01:36 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.8d0db91f07e0826596a3ccb75ba90008@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | thoughtpolice Priority: high | Status: new Component: Compiler (LLVM) | Milestone: 7.12.1 Resolution: | Version: Operating System: Unknown/Multiple | Keywords: llvm, Type of failure: None/Unknown | codegen Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: Phab:D530 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5d5abdca31cdb4db5303999778fa25c4a1371084/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5d5abdca31cdb4db5303999778fa25c4a1371084" llvmGen: move to LLVM 3.6 exclusively Summary: Rework llvmGen to use LLVM 3.6 exclusively. The plans for the 7.12 release are to ship LLVM alongside GHC in the interests of user (and developer) sanity. Along the way, refactor TNTC support to take advantage of the new `prefix` data support in LLVM 3.6. This allows us to drop the section-reordering component of the LLVM mangler. Test Plan: Validate, look at emitted code Reviewers: dterei, austin, scpmw Reviewed By: austin Subscribers: erikd, awson, spacekitteh, thomie, carter Differential Revision: https://phabricator.haskell.org/D530 GHC Trac Issues: #10074 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 14:01:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 14:01:36 -0000 Subject: [GHC] #9930: By default, a source code without extension would get overwritten by executable on *nix In-Reply-To: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> References: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> Message-ID: <064.a0a7a3228861e5cd8a81beb3091e8d9f@haskell.org> #9930: By default, a source code without extension would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"78833ca6305f0875add94351592e141c032cd088/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="78833ca6305f0875add94351592e141c032cd088" Don't overwrite input file by default Summary: If the default filename of the output executable coincides with that of main source file, throw an error instead of silently clobbering the input file. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D642 GHC Trac Issues: #9930 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 14:11:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 14:11:31 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error In-Reply-To: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> References: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> Message-ID: <062.b58de99f269ea53df1b111865a2008e3@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | typechecker plugin cycle imports Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jbracker): Replying to [comment:5 adamgundry]: > To try to clarify: it's not exactly true that the plugin needs to be **imported** into a module that uses it, although I believe the implementation works more-or-less like that, with some cleverness to avoid e.g. typeclass instances being brought in. The point is that if module `M` uses a plugin in module `P`, then we have to dynamically load `P` in order to typecheck `M`. Hence `P` cannot depend (directly or indirectly) on `M`! > > When `-fplugin=P` is used on the command-line, GHC tries to load `P` for every module being compiled, which might include `P` itself. This isn't exactly a cyclic import, but it's pretty close. Thank you for the clarification. I understand now. > > Maybe a link to this ticket, in case someone wants to know more about the issue? > > Yes. Done. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 14:11:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 14:11:40 -0000 Subject: [GHC] #9930: By default, a source code without extension would get overwritten by executable on *nix In-Reply-To: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> References: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> Message-ID: <064.051c3c9f1c16d8892b401c3cfb0a3eaa@haskell.org> #9930: By default, a source code without extension would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 14:50:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 14:50:43 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.7c5ea8c2b3cf26beb21ae0cbaec798fe@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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:"f46360ed7139ff25741b381647b0a0b6d1000d84/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f46360ed7139ff25741b381647b0a0b6d1000d84" Refactor the handling of quasi-quotes As Trac #10047 points out, a quasi-quotation [n|...blah...|] is supposed to behave exactly like $(n "...blah..."). But it doesn't! This was outright wrong: quasiquotes were being run even inside brackets. Now that TH supports both typed and untyped splices, a quasi-quote is properly regarded as a particular syntax for an untyped splice. But apart from that they should be treated the same. So this patch refactors the handling of quasiquotes to do just that. The changes touch quite a lot of files, but mostly in a routine way. The biggest changes by far are in RnSplice, and more minor changes in TcSplice. These are the places where there was real work to be done. Everything else is routine knock-on changes. * No more QuasiQuote forms in declarations, expressions, types, etc. So we get rid of these data constructors * HsBinds.QuasiQuoteD * HsExpr.HsSpliceE * HsPat.QuasiQuotePat * HsType.HsQuasiQuoteTy * We get rid of the HsQuasiQuote type altogether * Instead, we augment the HsExpr.HsSplice type to have three consructors, for the three types of splice: * HsTypedSplice * HsUntypedSplice * HsQuasiQuote There are some related changes in the data types in HsExpr near HsSplice. Specifically: PendingRnSplice, PendingTcSplice, UntypedSpliceFlavour. * In Hooks, we combine rnQuasiQuoteHook and rnRnSpliceHook into one. A smaller, clearer interface. * We have to update the Haddock submodule, to accommodate the hsSyn changes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 14:53:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 14:53:25 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.a8561255433d12b630208c97ce32c187@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => th/T10047 * resolution: => fixed * milestone: => 7.12.1 Comment: Very good bug report thank you. Now properly fixed. It's a big-ish change, and includes a simplification in the hooks API, so probably not for 7.10. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 15:06:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 15:06:30 -0000 Subject: [GHC] #10078: tcPluginStop of a type checker plugin is not called if an error occurs Message-ID: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> #10078: tcPluginStop of a type checker plugin is not called if an error occurs -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Linux Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called. I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called. === Test plugin `MyPlugin.hs`: {{{#!hs module MyPlugin ( plugin ) where import Plugins import TcRnTypes import TcPluginM plugin :: Plugin plugin = defaultPlugin { tcPlugin = \clos -> Just $ TcPlugin { tcPluginInit = tcPluginIO $ putStrLn ">>> Plugin Init" , tcPluginSolve = \_ _ _ _ -> do tcPluginIO $ putStrLn ">>> Plugin Solve" return $ TcPluginOk [] [] , tcPluginStop = \_ -> tcPluginIO $ putStrLn ">>> Plugin Stop" } } }}} === Minimal example (with type error) `Main.hs`: {{{#!hs {-# OPTIONS_GHC -fplugin MyPlugin #-} module Main where main :: (Monad m) => m () main = do return 1 }}} Compiling this will lead to the following output: {{{ $ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs [2 of 2] Compiling Main ( Main.hs, Main.o ) >>> Plugin Init >>> Plugin Solve >>> Plugin Solve >>> Plugin Solve Main.hs:6:10: Could not deduce (Num ()) arising from the literal ?1? from the context: Monad m bound by the type signature for: main :: Monad m => m () at Main.hs:4:9-25 In the first argument of ?return?, namely ?1? In a stmt of a 'do' block: return 1 In the expression: do { return 1 } }}} Which means `tcPluginStop` was _not_ called. === Minimal example (without type error) `Main.hs`: {{{#!hs {-# OPTIONS_GHC -fplugin MyPlugin #-} module Main where main :: (Monad m) => m () main = do return () }}} Compiling this will lead to the following output: {{{ $ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs [2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed] >>> Plugin Init >>> Plugin Solve >>> Plugin Solve >>> Plugin Stop Linking Main ... }}} Which means `tcPluginStop` _was_ called. === Possible solution As far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from {{{#!hs withTcPlugins :: HscEnv -> TcM a -> TcM a withTcPlugins hsc_env m = do plugins <- liftIO (loadTcPlugins hsc_env) case plugins of [] -> m -- Common fast case _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins res <- updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m mapM_ runTcPluginM stops return res where startPlugin (TcPlugin start solve stop) = do s <- runTcPluginM start return (solve s, stop s) }}} to {{{#!hs withTcPlugins :: HscEnv -> TcM a -> TcM a withTcPlugins hsc_env m = do plugins <- liftIO (loadTcPlugins hsc_env) case plugins of [] -> m -- Common fast case _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins eitherRes <- tryM $ do updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m mapM_ runTcPluginM stops case eitherRes of Left e -> failM Right res -> return res where startPlugin (TcPlugin start solve stop) = do s <- runTcPluginM start return (solve s, stop s) }}} . I have tried this. It compiles and my minimal example delivers the correct result. Are there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 15:09:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 15:09:18 -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.1d9993b8a9892f92bec811f69934e537@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: Richard any comments? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 15:13:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 15:13:52 -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.3d9ad76f278bd8ebe19f3e30f4000aab@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new 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: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 15:18:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 15:18:34 -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.b75fbb58434199ae2b895d11d33ac5be@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new 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: -------------------------------------+------------------------------------- Comment (by simonmar): I think the problem here is that you're trying to use `-O` in conjunction with the interpreter, which we normally don't do because optimisation can introduce unboxed tuples, which the interpreter can't handle. I suspect that you've uncovered another case that isn't handled when we try to use -O with the interpreter, but since we don't have any plans to handle that combination I'm not inclined to try to fix this particular problem. We will look into why we aren't catching the -O/interpreter combination and make it fail in a civilized way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 15:18:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 15:18:38 -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.179bef2a298c8973221212e74d84b733@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new 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: -------------------------------------+------------------------------------- Comment (by simonpj): So the fixes needed are: * Complain in a civilised way if you are using the interpreter with `-O`. Add a clear `Note` to explain why, enumerating all the things (that we know of) which can go wrong. * Add a clear Note in `FloatOut` to explain that the un-handled case concerns breakpoints (which isn't at all clear right now), and that breakpoints means the interpreter, and the interpreter means no `-O` (refer to Note from the first bullet). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 15:19:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 15:19:16 -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.34d3d92ca55f5e1585b3bab53f846791@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new 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: -------------------------------------+------------------------------------- Comment (by thoughtpolice): (For interested readers, the check we currently have is in `setOptLevel` in `DynFlags.hs`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 15:19:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 15:19:38 -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.5b6ac2af28a46cbbd5bbbc23611a91c7@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new 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: -------------------------------------+------------------------------------- Comment (by simonpj): Is anyone willing to execute on this? Simple, a little fiddly. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 15:56:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 15:56:47 -0000 Subject: [GHC] #10078: tcPluginStop of a type checker plugin is not called if an error occurs In-Reply-To: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> References: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> Message-ID: <062.2b7998e25fd700a65728330bedd7ff46@haskell.org> #10078: tcPluginStop of a type checker plugin is not called if an error occurs -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: gridaphobe, diatchki (added) Comment: Sounds fine to me. Thanks for the detailed report and for proposing a fix! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 16:10:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 16:10:42 -0000 Subject: [GHC] #10078: tcPluginStop of a type checker plugin is not called if an error occurs In-Reply-To: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> References: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> Message-ID: <062.fe77d0194d2dabcec904b29834d4852f@haskell.org> #10078: tcPluginStop of a type checker plugin is not called if an error occurs -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Good catch, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 16:15:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 16:15:26 -0000 Subject: [GHC] #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.2487828aff9deefdd230028521d36fee@haskell.org> #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hesselink): I can reproduce this on a Mac (OS X 10.9.5, GHC 7.10.0.20150123). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 16:21:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 16:21:50 -0000 Subject: [GHC] #414: GHC does not eforce that Main exports main In-Reply-To: <046.38fe8da23abfc42f9ad2cb0e14b8afda@haskell.org> References: <046.38fe8da23abfc42f9ad2cb0e14b8afda@haskell.org> Message-ID: <061.3a87e907452163afa1314bf1f077a536@haskell.org> #414: GHC does not eforce that Main exports main -------------------------------------+------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: lowest | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | module/T414 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: mod174 => module/T414 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 17:20:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 17:20:46 -0000 Subject: [GHC] #7765: Odd error message for `runghc` with missing `main` function. In-Reply-To: <050.8542064156faf46af950f88e560aca22@haskell.org> References: <050.8542064156faf46af950f88e560aca22@haskell.org> Message-ID: <065.4721a16da5a7082b28a467bab79ab562@haskell.org> #7765: Odd error message for `runghc` with missing `main` function. -------------------------------------+------------------------------------- Reporter: isaacdupree | Owner: Type: bug | Status: patch 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: #414 | module/T7765 | Blocking: | Differential Revisions: Phab:D649 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => module/T7765 * differential: => Phab:D649 * related: => #414 Comment: With Phab:D649, `Main` without `main` is always an error, regardless of the mode of operation: `ghc`, `ghci` or `runhaskell` (=`ghc -e main`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 17:30:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 17:30:57 -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.b0825e4667bb0bc84423dc2ea57c3e81@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: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: closed => new * resolution: invalid => Comment: Re-opening, as I believe it was Simon's intention to keep this one open ([#comment:4]) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 17:58:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 17:58:19 -0000 Subject: [GHC] #10076: Don't suppress warnings in the presence of errors In-Reply-To: <048.07984c34d4e400833c1a386400621378@haskell.org> References: <048.07984c34d4e400833c1a386400621378@haskell.org> Message-ID: <063.624570182c08fa5f876873fd98c49f0a@haskell.org> #10076: Don't suppress warnings in the presence of errors -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): This (displaying warnings also when there are errors) is the topic of at least one other Trac ticket, though I'm too lazy to look for it right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 18:52:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 18:52:37 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.6f43686e0193e72e975fac2fe6cc3b75@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 19:21:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 19:21:19 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.b6ca473fecb29c58e8272aea9fe78b6c@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Changes (by ekmett): * owner: hvr => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 19:21:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 19:21:42 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.e6bc86ab88158f6f607cc3d837ddf7dc@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Changes (by ekmett): * owner: => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 19:22:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 19:22:37 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.633fb3e4fffdb9a6037d9d8f5cffc468@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Changes (by ekmett): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 19:24:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 19:24:01 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.7b7d054266218a61933d255c16561b7a@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Comment (by ekmett): I've re-opened this ticket while we seek feedback via https://goo.gl/forms/XP1W2JdfpX to connote its as-yet-ambiguous fate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 20:50:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 20:50:57 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.5285856c57734814fb168db875e26704@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fanael): It's not Windows, it's binutils being broken (nothing new). For example, LLVM emits this: {{{ .quad S1kt_srt$def-Main_main1_info$def # @"Main_main1_info$def" .quad 4294967299 # 0x100000003 .quad 0 # 0x0 .quad 64424509455 # 0xf0000000f Main_main1_info$def: }}} With GDB, we can learn that this value should equal {{{ (gdb) p ((char*)&S1kt_srt$def - (char*)&Main_main1_info$def) $1 = 3062336 }}} But what actually lands in the executable is {{{ (gdb) x/d Main_main1_info$def - 32 0x4015b0 : 3062340 }}} Makes me wonder if binutils devs are aware of the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 21:37:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 21:37:50 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.a9a3cfd9e7a873123dfcbf7459c575d7@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Did you forget to add `./th/T10047.run.stderr`? I observe {{{ Actual stderr output differs from expected: --- /dev/null 2014-07-11 16:48:13.679453102 +0200 +++ ./th/T10047.run.stderr 2015-02-10 19:42:50.001947139 +0100 @@ -0,0 +1,6 @@ + +T10047.hs:6:5: Warning: + Fields of ?QuasiQuoter? not initialised: quotePat, quoteType, + quoteDec + In the expression: QuasiQuoter {quoteExp = dyn} + In an equation for ?n?: n = QuasiQuoter {quoteExp = dyn} *** unexpected failure for T10047(ghci) }}} on https://raw.githubusercontent.com/nomeata/ghc-speed- logs/master/f46360ed7139ff25741b381647b0a0b6d1000d84.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 22:01:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 22:01:45 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.5482901e25cd8f83be7484582a554704@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fanael): I reported the binutils bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17955. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 10 23:24:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Feb 2015 23:24:55 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.1455965ae6f806b23515de805b128a05@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T10047 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1d982ba10f590828b78eba992e73315dee33f78a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1d982ba10f590828b78eba992e73315dee33f78a" Do not complain about missing fields in Trac #10047 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 07:34:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 07:34:29 -0000 Subject: [GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b Message-ID: <044.27703c964d72a1c41fb88d9bf980378d@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 (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: | -------------------------------------+------------------------------------- Hello, I ran into what appears to be a regression in the Coercible solver since 7.8.4. This is as small as I've managed to get my example case. {{{ {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleContexts #-} module Bug where import Control.Applicative import Data.Coerce broken :: Bizarre (->) w => w a b t -> () broken = getConst #. bazaar (Const #. const ()) class Profunctor p where (#.) :: Coercible c b => (b -> c) -> p a b -> p a c class Bizarre p w | w -> p where bazaar :: Applicative f => p a (f b) -> w a b t -> f t }}} {{{ Bug.hs:10:36: Couldn't match representation of type ?()? with that of ?Const () b? Relevant role signatures: type role Const representational phantom Relevant bindings include broken :: w a b t -> () (bound at Bug.hs:10:1) In the first argument of ?bazaar?, namely ?(Const #. const ())? In the second argument of ?(#.)?, namely ?bazaar (Const #. const ())? In the expression: getConst #. bazaar (Const #. const ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 07:36:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 07:36: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.cc162acc82c632366ba300afdb9738ce@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Description changed by glguy: Old description: > Hello, I ran into what appears to be a regression in the Coercible solver > since 7.8.4. This is as small as I've managed to get my example case. > > {{{ > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE FlexibleContexts #-} > module Bug where > > import Control.Applicative > import Data.Coerce > > broken :: Bizarre (->) w => w a b t -> () > broken = getConst #. bazaar (Const #. const ()) > > class Profunctor p where > (#.) :: Coercible c b => (b -> c) -> p a b -> p a c > > class Bizarre p w | w -> p where > bazaar :: Applicative f => p a (f b) -> w a b t -> f t > }}} > > {{{ > Bug.hs:10:36: > Couldn't match representation of type ?()? > with that of ?Const () b? > Relevant role signatures: type role Const representational phantom > Relevant bindings include > broken :: w a b t -> () (bound at Bug.hs:10:1) > In the first argument of ?bazaar?, namely ?(Const #. const ())? > In the second argument of ?(#.)?, namely > ?bazaar (Const #. const ())? > In the expression: getConst #. bazaar (Const #. const ()) > }}} New description: Hello, I ran into what appears to be a regression in the Coercible solver since 7.8.4. This is as small as I've managed to get my example case. {{{ {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleContexts #-} module Bug where import Control.Applicative import Data.Coerce broken :: Bizarre (->) w => w a b t -> () broken = getConst #. bazaar (Const #. const ()) class Profunctor p where (#.) :: Coercible c b => (b -> c) -> p a b -> p a c instance Profunctor (->) where (#.) = (.) class Bizarre p w | w -> p where bazaar :: Applicative f => p a (f b) -> w a b t -> f t }}} {{{ Bug.hs:10:36: Couldn't match representation of type ?()? with that of ?Const () b? Relevant role signatures: type role Const representational phantom Relevant bindings include broken :: w a b t -> () (bound at Bug.hs:10:1) In the first argument of ?bazaar?, namely ?(Const #. const ())? In the second argument of ?(#.)?, namely ?bazaar (Const #. const ())? In the expression: getConst #. bazaar (Const #. const ()) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 08:15:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 08:15:11 -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.3c501c09c004c8bb25af843ff0782f0b@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | 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: | -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => highest * milestone: => 7.10.1 Comment: setting high priority to make sure it gets noticed asap for triaging -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 09:40:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 09:40:38 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.4fcb1d5c4e7e2fe11bf6ef725c027d7f@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:40 George]: > 2) Are all the proposed changes in 7.10RC2? > > wrt doc I am referring to the GHC User's Guide and Hackage documentation such as https://hackage.haskell.org/package/base-4.7.0.2/docs/Data- List.html You can take a look at the base-4.8 candidate documentation for the mean- time which is fairly recent: http://hackage.haskell.org/package/base-4.8.0.0/candidate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 11:16:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 11:16:32 -0000 Subject: [GHC] #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt In-Reply-To: <050.8ec6823346e7fe6fc27e65a4900502d1@haskell.org> References: <050.8ec6823346e7fe6fc27e65a4900502d1@haskell.org> Message-ID: <065.d15553aa0e70ed94a4ee6ba55ed4ed17@haskell.org> #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 Simon Peyton Jones ): In [changeset:"6ff3db92140e3ac8cbda50d1a4aab976350ac8c4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6ff3db92140e3ac8cbda50d1a4aab976350ac8c4" nameIsLocalOrFrom should include interactive modules The provoking cause was Trac #10019, but it revealed that nameIsLocalOrFrom should really include all interactive modules (ones from the 'interactive' package). Previously we had some ad-hoc 'isInteractiveModule' tests with some (but not all) the calls to nameIsLocalOrFrom. See the new comments with Name.nameIsLocalOrFrom. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 11:17:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 11:17:46 -0000 Subject: [GHC] #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt In-Reply-To: <050.8ec6823346e7fe6fc27e65a4900502d1@haskell.org> References: <050.8ec6823346e7fe6fc27e65a4900502d1@haskell.org> Message-ID: <065.64fb677363b03a8173bd1c5a6146c337@haskell.org> #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T10019 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => th/T10019 Comment: Great report thank you. Merge to 7.10 if poss SImon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 11:58:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 11:58:30 -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.82c8781a1f33f57870aa7c74aea9e4c4@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: highest | 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire Comment: Richard, this is in your bailiwick. The problem is in `TcCanonical`: {{{ -- When working with ReprEq, unwrap newtypes next. -- Otherwise, a ~ Id a wouldn't get solved 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 can_eq_nc' rdr_env envs ev ReprEq ty1 ps_ty1 ty2 _ | Just (co, ty2') <- tcTopNormaliseNewTypeTF_maybe envs rdr_env ty2 = can_eq_newtype_nc rdr_env ev IsSwapped co ty2 ty2' ty1 ps_ty1 }}} This is done before flattening. At that stage the constaint looks like `Coercible a (f b)`, but we already know `a := ()` `f := Const ()`, so the equation doesn't match. But then we don't see the newtype expansion at all. I suppose we have to flatten ''before'' trying the newtype expansion. Which is a bit awkward in practice. I suspect that we should have a new invariant for `CTyEqCan`, that in canonical constraint `a ~R ty`, the rhs `ty` is never a saturated newtype application. And then enforce that invariant. That would deal with the `CTyEqCan` case. Then we need to do something in `try_decompose_repr_app`. (Acutally that function looks wrong to me. Suppose we had `f Age ~R g Int`. Then if `f` and `g` both flattened to `Maybe` we should decompose, not fail.) This is an outright bug; must fix for 7.10. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 12:19:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 12:19:38 -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.a2bce2fa53a9706560800f73e4be935f@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #7788 Comment: This looks like a duplicate of #7788. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 12:23:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 12:23:07 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.960b42016de1280afbd4fa7331dfc54e@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.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 | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: simonpj => goldfire * related: => #8550 * milestone: 7.12.1 => 7.10.1 Comment: I just noticed that I had been asked to do this, and I think it would be nice in 7.10. However, the fix would potentially be user-facing: A type-family-heavy program that compiles on 7.10.1RC2 might need to set `-ftype-function- depth` after the fix. Is that acceptable at this point? Also, time is very precious for me before Feb. 27. I can get right on this Mar. 2. (See also #8550, which is probably a dup of this bug.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 13:31:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 13:31:21 -0000 Subject: [GHC] #10018: Cannot define custom fixity for infix data constructors in GHCi In-Reply-To: <050.b73ae7970094272181854c9a26f7e4d3@haskell.org> References: <050.b73ae7970094272181854c9a26f7e4d3@haskell.org> Message-ID: <065.3e7482b7fc257c8294a3b32e99d0aa4e@haskell.org> #10018: Cannot define custom fixity for infix data constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: Whoops. I originally thought this was a separate issue from [https://ghc.haskell.org/trac/ghc/ticket/9830 9830], but I can't duplicate this issue on GHC 7.10-rc2, so it appears that this issue was also fixed as a result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 15:19:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 15:19:41 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault Message-ID: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I am learning Haskell and wrote a program that writes some strings to stdout infinitely by recursing in an IO action. It seems such a simple construct crashes on FreeBSD when Ctrl+C is pressed to interrupt it. I have been able to reduce it to a simple case like this: {{{#!hs main = do putStrLn "hello world" main }}} I compiled it with {{{ ghc --make hello.hs }}} Then pressed Ctrl+C and immediately got: {{{ [...] hello world hello world hello world hello world ^CSegmentation fault (core dumped) }}} Here is the backtrace of the crash: {{{ (gdb) bt #0 0x000000000047cdd7 in generic_handler () #1 0x000000080147c467 in swapcontext () from /lib/libthr.so.3 #2 0x000000080147c062 in sigaction () from /lib/libthr.so.3 #3 #4 0x00000008017d7b7a in select () from /lib/libc.so.7 #5 0x0000000801479b32 in select () from /lib/libthr.so.3 #6 0x000000000043cb13 in fdReady () #7 0x000000000044751c in base_GHCziIOziFD_zdwa3_info () #8 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 15:26:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 15:26:16 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.b45750d68f7870dd939b3f0a801119ae@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by nakal: Old description: > I am learning Haskell and wrote a program that writes some strings to > stdout infinitely by recursing in an IO action. It seems such a simple > construct crashes on FreeBSD when Ctrl+C is pressed to interrupt it. > > I have been able to reduce it to a simple case like this: > > {{{#!hs > main = do > putStrLn "hello world" > main > }}} > > I compiled it with > {{{ > ghc --make hello.hs > }}} > > Then pressed Ctrl+C and immediately got: > {{{ > [...] > hello world > hello world > hello world > hello world > ^CSegmentation fault (core dumped) > }}} > > Here is the backtrace of the crash: > > {{{ > (gdb) bt > #0 0x000000000047cdd7 in generic_handler () > #1 0x000000080147c467 in swapcontext () from /lib/libthr.so.3 > #2 0x000000080147c062 in sigaction () from /lib/libthr.so.3 > #3 > #4 0x00000008017d7b7a in select () from /lib/libc.so.7 > #5 0x0000000801479b32 in select () from /lib/libthr.so.3 > #6 0x000000000043cb13 in fdReady () > #7 0x000000000044751c in base_GHCziIOziFD_zdwa3_info () > #8 0x0000000000000000 in ?? () > }}} New description: I am learning Haskell and wrote a program that writes some strings to stdout infinitely by recursing in an IO action. It seems such a simple construct crashes on FreeBSD when Ctrl+C is pressed to interrupt it. I have been able to reduce it to a simple case like this: {{{#!hs main = do putStrLn "hello world" main }}} I compiled it with {{{ ghc --make hello.hs }}} Ran it and then pressed Ctrl+C and immediately got: {{{ [...] hello world hello world hello world hello world ^CSegmentation fault (core dumped) }}} Here is the backtrace of the crash: {{{ (gdb) bt #0 0x000000000047cdd7 in generic_handler () #1 0x000000080147c467 in swapcontext () from /lib/libthr.so.3 #2 0x000000080147c062 in sigaction () from /lib/libthr.so.3 #3 #4 0x00000008017d7b7a in select () from /lib/libc.so.7 #5 0x0000000801479b32 in select () from /lib/libthr.so.3 #6 0x000000000043cb13 in fdReady () #7 0x000000000044751c in base_GHCziIOziFD_zdwa3_info () #8 0x0000000000000000 in ?? () }}} Operating system version is: FreeBSD 10.1-RELEASE-p5 (GENERIC) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 16:19:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 16:19:21 -0000 Subject: [GHC] #10081: SIGTERM ignored when process has been detached from terminal Message-ID: <044.1f8bc4458608289c276bfd2ddfa7272f@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/unix | Operating System: FreeBSD Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've tried to write a simple Unix daemon that reacts to signals. Here is the reduced source code sample: {{{#!hs 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 hPutStrLn stderr "Signal received.\n" throwTo tid ExitSuccess }}} Such daemons usually run in background without a terminal attached. I verified that I can kill the process after being started on the terminal: {{{ > ./daemon Signal received. }}} With: {{{ > killall daemon }}} in other terminal. Other test, when I run it in background: {{{ > ./daemon (press Ctrl+Z) > bg > killall daemon Signal received. }}} This case is also ok. Now the third test which is also OK: {{{ > ./daemon > log 2>&1 (press Ctrl+Z) > bg > exit }}} In second terminal: {{{ > cat log > killall daemon > cat log Signal received. > killall daemon No matching processes belonging to you were found }}} Now the fourth test which is simply without a log file and this one fails: {{{ > ./daemon (press Ctrl+Z) > bg > exit }}} On some other terminal try to kill the process: {{{ > killall xxx > killall xxx > killall xxx > killall -9 xxx > killall xxx No matching processes belonging to you were found }}} Signal 9 (SIGKILL) kills the process hard without the signal trap. That's why it works, of course, but SIGTERM is being ignored for some reason. Maybe I am forgetting something, but in my opinion this should end the process properly, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 16:56:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 16:56:55 -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.ee67986d604dd4ba9f0ce0be73aa42a6@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Is `openEndedPipe` SIGPIPE? Then, in the last test, as you have exited the shell that invoked the daemon, when you send it a SIGTERM, wouldn't the daemon try to print an error message `trap`, and then receive a SIGPIPE since its stderr is closed, and then enter `trap` again to handle that signal, etc.? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 17:59:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 17:59: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.fef6c735258e7e4e18843dd0c4beae49@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: highest | 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: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) Comment: Thanks, Simon. We've constructed a workaround for now, but this is pretty much the last thing we have in the way of shedding 117 performance-motivated `unsafeCoerce`'s in favor of `coerce`. =) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 18:00:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 18:00:19 -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.c7557db6bfd8a22b23a5f2b95af3e9ca@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: highest | 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 goldfire): I'm on it right this minute, actually. Seems quite straightforward to solve. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 18:06:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 18:06:52 -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.da17b1ce63ac17b3c4961e1af8b7da1b@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: highest | 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 goldfire): Yep. Fixed. Will validate and push later today. {{{ try_decompose_repr_app :: CtEvidence -> TcType -> TcType -> TcS (StopOrContinue Ct) -- Preconditions: like try_decompose_app, but also -- ev has a representational try_decompose_repr_app ev ty1 ty2 | ty1 `eqType` ty2 -- See Note [AppTy reflexivity check] = canEqReflexive ev ReprEq ty1 | AppTy {} <- ty1 = canEqFailure ev ReprEq ty1 ty2 | AppTy {} <- ty2 = canEqFailure ev ReprEq ty1 ty2 | otherwise -- flattening in can_eq_wanted_app exposed some TyConApps! = ASSERT2( isJust (tcSplitTyConApp_maybe ty1) || isJust (tcSplitTyConApp_maybe ty2) , ppr ty1 $$ ppr ty2 ) -- If this assertion fails, we may fall -- into an infinite loop canEqNC ev ReprEq ty1 ty2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 18:24:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 18:24:56 -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.c1a8b981cfa7a2199ca1acdefbe3919d@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: -------------------------------------+------------------------------------- Changes (by k-bx): * owner: => k-bx -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 18:57:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 18:57:34 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.721391df82573900e013625fe5b07e86@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.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 | -------------------------------------+------------------------------------- Comment (by goldfire): Just took a quick look at this, as I was in the area. This will take some plumbing to implement right, sadly. The problem is that the type family reduction happens in the bowels of the flattening algorithm. To do this right, we need to update the `CtLoc` of the relevant constraint, but there's no good way to do that from the middle of the flattener. Two ways forward: 1. Install the plumbing. I vote that this should be a new `FlatM` monad (built on `TcS`) that allows updating of the `CtLoc` currently stored in the `FlattenEnv`. `FlatM` would gather up the `FlattenEnv` stuff, the `runFlatten` stuff, and this new type-family-depth-counting stuff. Seems like enough stuff to make it a new structure. 2. Have a local counter just for the new, eager type family reduction. We have access to `DynFlags`, of course, so we can check if the number of eager reductions is more than requested. We can even add the number of eager reductions to the number of reductions done previously. What we can't do is record the number of eager reductions. So, if the stack depth were 200, then this plan (2) would allow, say, 190 eager reductions at one go, then some other solving, and then another 190 eager reductions, and then some solving, and so on. The depth is still bounded, but it makes it nigh impossible for a programmer to relate their choice of `-ftype- function-depth` to GHC's behavior, as it all depends on where the reduction takes place. Thoughts? Still no promises on getting to this for real before March, I'm afraid, especially for option 1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 19:21:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 19:21:35 -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.58274d8cef255f866a7771f2cdbd8267@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nakal): As far as I know, SIGPIPE will occur, if a pipe was there, but it's closed later and the main process still tries to write to it. I think detached programs don't get SIGPIPE when they write something to stdout/stderr. I have to mention some more facts here. I tried to catch many more signals to check what happens. My small program originally did not catch SIGPIPE and the behavior is the same. You can try it. There is no endless loop when you send the signal. The process is still idle. I think that the main process still works correctly without interruptions, but I will verify it later to be sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 19:33:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 19:33:04 -0000 Subject: [GHC] #10018: Cannot define custom fixity for infix data constructors in GHCi In-Reply-To: <050.b73ae7970094272181854c9a26f7e4d3@haskell.org> References: <050.b73ae7970094272181854c9a26f7e4d3@haskell.org> Message-ID: <065.6d1929f1efe42a5fa1de17762600432b@haskell.org> #10018: Cannot define custom fixity for infix data constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * version: 7.8.4 => 7.10.1-rc2 * resolution: fixed => Comment: Sorry, it turns out that the bug is more nuanced than I thought. I prematurely closed this ticket when I discovered that a {{{deriving Show}}} clause does in fact pick up on a custom fixity: {{{ $ ghci GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help ?> data Infix a b = a :@: b deriving Show; infix 4 :@: ?> showsPrec 4 ('a' :@: 'b') "" "'a' :@: 'b'" ?> showsPrec 5 ('a' :@: 'b') "" "('a' :@: 'b')" }}} So as far as {{{Show}}} is concerned, {{{:@:}}} is {{{infix 4}}}. However, it behaves as {{{infixl 11}}} when it is actually used: {{{ ?> 'a' :@: 'b' :@: 'c' ('a' :@: 'b') :@: 'c' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 20:30:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 20:30: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.aaf3b0ebcaae27c16428408d50d059c2@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: highest | 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 Richard Eisenberg ): In [changeset:"befe2d7c8902096dd184ebca3f7f135ee5f479e8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="befe2d7c8902096dd184ebca3f7f135ee5f479e8" Fix #10079 by recurring after flattening exposes a TyConApp. Previously, try_decompose_nom_app was smart enough to recur if flattening exposed a TyConApp, but try_decompose_repr_app was not. Now, if neither type in try_decompose_repr_app is an AppTy, recur. Seems all straightforward enough to avoid a Note. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 20:32:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 20:32:31 -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.fb07fb26083d3abc65ef3f6ee9228b86@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: merge Priority: highest | 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: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => indexed-types/should_compile/T10079 Comment: All set, now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 21:31:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 21:31:19 -0000 Subject: [GHC] #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt In-Reply-To: <050.8ec6823346e7fe6fc27e65a4900502d1@haskell.org> References: <050.8ec6823346e7fe6fc27e65a4900502d1@haskell.org> Message-ID: <065.e253209c2236001ba1c851a3b85dcbe5@haskell.org> #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T10019 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 21:37:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 21:37:58 -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.2d682caf910d02aaea3eeffbe5fab84e@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 slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 21:57:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 21:57:50 -0000 Subject: [GHC] #10082: Church Booleans - xor Message-ID: <047.8503893f9bcf411059cd0b2e1a640aa4@haskell.org> #10082: Church Booleans - xor -------------------------------------+------------------------------------- Reporter: honza889 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I use following implementation of Church Booleans, all is ok: {{{#!hs lTrue = \x y -> x lFalse = \x y -> y lNot = \t -> t lFalse lTrue lXor = \u v -> u (lNot v) (lNot lNot v) lXor' = \u v -> u (v lFalse lTrue) (v lTrue lFalse) }}} But this simplified versions of lXor fails, if first parameter is lFalse: {{{#!hs lXor'' = \u v -> u (lNot v) (v) -- not work, bug in ghc? lXor''' = \u v -> u (lNot v) v -- not work, bug in ghc? }}} {{{#!hs GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :l lambda.hs [1 of 1] Compiling Main ( lambda.hs, interpreted ) Ok, modules loaded: Main. *Main> (lXor'' lFalse lFalse) 1 0 :3:1: Non type-variable argument in the constraint: Num (t5 -> t4 -> t5) (Use FlexibleContexts to permit this) When checking that ?it? has the inferred type it :: forall t4 t5. Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 :3:24: Could not deduce (Num (t20 -> t30 -> t30)) arising from the literal ?1? from the context (Num (t5 -> t4 -> t5)) bound by the inferred type of it :: Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 at :3:1-26 The type variables ?t20?, ?t30? are ambiguous In the third argument of ?lXor''?, namely ?1? In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for ?it?: it = (lXor'' lFalse lFalse) 1 0 }}} Because both lXor implementations in first example works ok, I believe this is bug in ghc. But similar problem occure in older versions of ghc: {{{#!hs 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. Prelude> :l lambda.hs [1 of 1] Compiling Main ( lambda.hs, interpreted ) Ok, modules loaded: Main. *Main> (lXor'' lFalse lFalse) 1 0 :3:24: No instance for (Num (t20 -> t30 -> t30)) arising from the literal `1' Possible fix: add an instance declaration for (Num (t20 -> t30 -> t30)) In the third argument of lXor'', namely `1' In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 :3:26: No instance for (Num (t50 -> t40 -> t50)) arising from the literal `0' Possible fix: add an instance declaration for (Num (t50 -> t40 -> t50)) In the fourth argument of lXor'', namely `0' In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 21:58:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 21:58:58 -0000 Subject: [GHC] #10082: Church Booleans - xor In-Reply-To: <047.8503893f9bcf411059cd0b2e1a640aa4@haskell.org> References: <047.8503893f9bcf411059cd0b2e1a640aa4@haskell.org> Message-ID: <062.d00fae9f6650d715f087f7cfc515cbce@haskell.org> #10082: Church Booleans - xor -------------------------------------+------------------------------------- Reporter: honza889 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 honza889): * cc: honza889@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 22:00:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 22:00:45 -0000 Subject: [GHC] #10082: Church Booleans - xor In-Reply-To: <047.8503893f9bcf411059cd0b2e1a640aa4@haskell.org> References: <047.8503893f9bcf411059cd0b2e1a640aa4@haskell.org> Message-ID: <062.828069c5995064a961afbc156ee09503@haskell.org> #10082: Church Booleans - xor -------------------------------------+------------------------------------- Reporter: honza889 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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: -------------------------------------+------------------------------------- Description changed by honza889: Old description: > When I use following implementation of Church Booleans, all is ok: > {{{#!hs > lTrue = \x y -> x > lFalse = \x y -> y > lNot = \t -> t lFalse lTrue > lXor = \u v -> u (lNot v) (lNot lNot v) > lXor' = \u v -> u (v lFalse lTrue) (v lTrue lFalse) > }}} > > But this simplified versions of lXor fails, if first parameter is lFalse: > {{{#!hs > lXor'' = \u v -> u (lNot v) (v) -- not work, bug in ghc? > lXor''' = \u v -> u (lNot v) v -- not work, bug in ghc? > }}} > > {{{#!hs > GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help > Prelude> :l lambda.hs > [1 of 1] Compiling Main ( lambda.hs, interpreted ) > Ok, modules loaded: Main. > *Main> (lXor'' lFalse lFalse) 1 0 > > :3:1: > Non type-variable argument in the constraint: Num (t5 -> t4 -> t5) > (Use FlexibleContexts to permit this) > When checking that ?it? has the inferred type > it :: forall t4 t5. Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 > > :3:24: > Could not deduce (Num (t20 -> t30 -> t30)) > arising from the literal ?1? > from the context (Num (t5 -> t4 -> t5)) > bound by the inferred type of > it :: Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 > at :3:1-26 > The type variables ?t20?, ?t30? are ambiguous > In the third argument of ?lXor''?, namely ?1? > In the expression: (lXor'' lFalse lFalse) 1 0 > In an equation for ?it?: it = (lXor'' lFalse lFalse) 1 0 > }}} > > Because both lXor implementations in first example works ok, I believe > this is bug in ghc. But similar problem occure in older versions of ghc: > > {{{#!hs > 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. > Prelude> :l lambda.hs > [1 of 1] Compiling Main ( lambda.hs, interpreted ) > Ok, modules loaded: Main. > *Main> (lXor'' lFalse lFalse) 1 0 > > :3:24: > No instance for (Num (t20 -> t30 -> t30)) > arising from the literal `1' > Possible fix: > add an instance declaration for (Num (t20 -> t30 -> t30)) > In the third argument of lXor'', namely `1' > In the expression: (lXor'' lFalse lFalse) 1 0 > In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 > > :3:26: > No instance for (Num (t50 -> t40 -> t50)) > arising from the literal `0' > Possible fix: > add an instance declaration for (Num (t50 -> t40 -> t50)) > In the fourth argument of lXor'', namely `0' > In the expression: (lXor'' lFalse lFalse) 1 0 > In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 > }}} New description: When I use following implementation of Church Booleans, all is ok: {{{#!hs lTrue = \x y -> x lFalse = \x y -> y lNot = \t -> t lFalse lTrue lXor = \u v -> u (lNot v) (lNot lNot v) lXor' = \u v -> u (v lFalse lTrue) (v lTrue lFalse) }}} But this simplified versions of lXor fails, if first parameter is lFalse: {{{#!hs lXor'' = \u v -> u (lNot v) (v) -- not work, bug in ghc? lXor''' = \u v -> u (lNot v) v -- not work, bug in ghc? }}} {{{#!hs GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :l lambda.hs [1 of 1] Compiling Main ( lambda.hs, interpreted ) Ok, modules loaded: Main. *Main> (lXor'' lFalse lFalse) 1 0 :3:1: Non type-variable argument in the constraint: Num (t5 -> t4 -> t5) (Use FlexibleContexts to permit this) When checking that ?it? has the inferred type it :: forall t4 t5. Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 :3:24: Could not deduce (Num (t20 -> t30 -> t30)) arising from the literal ?1? from the context (Num (t5 -> t4 -> t5)) bound by the inferred type of it :: Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 at :3:1-26 The type variables ?t20?, ?t30? are ambiguous In the third argument of ?lXor''?, namely ?1? In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for ?it?: it = (lXor'' lFalse lFalse) 1 0 }}} Because both lXor implementations in first example works ok and simplified implementation should be equivalent, I believe this is bug in ghc. But similar problem occure also in older versions of ghc: {{{#!hs 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. Prelude> :l lambda.hs [1 of 1] Compiling Main ( lambda.hs, interpreted ) Ok, modules loaded: Main. *Main> (lXor'' lFalse lFalse) 1 0 :3:24: No instance for (Num (t20 -> t30 -> t30)) arising from the literal `1' Possible fix: add an instance declaration for (Num (t20 -> t30 -> t30)) In the third argument of lXor'', namely `1' In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 :3:26: No instance for (Num (t50 -> t40 -> t50)) arising from the literal `0' Possible fix: add an instance declaration for (Num (t50 -> t40 -> t50)) In the fourth argument of lXor'', namely `0' In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 11 23:22:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Feb 2015 23:22:22 -0000 Subject: [GHC] #10082: Church Booleans - xor In-Reply-To: <047.8503893f9bcf411059cd0b2e1a640aa4@haskell.org> References: <047.8503893f9bcf411059cd0b2e1a640aa4@haskell.org> Message-ID: <062.393962b7ff90edcc4a9f68a6e5d71104@haskell.org> #10082: Church Booleans - xor -------------------------------------+------------------------------------- Reporter: honza889 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: invalid | 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 simonpj): * status: new => closed * resolution: => invalid Comment: You are trying to use higher rank types here, so you need type signatures. (See [http://research.microsoft.com/en-us/um/people/simonpj/papers/higher- rank/index.htm Practical type inference for higher rank types]). This works: {{{ {-# LANGUAGE RankNTypes #-} module T10082 where type CBool = forall a. a->a->a lTrue :: CBool lTrue = \x y -> x lFalse :: CBool lFalse = \x y -> y lNot :: CBool -> CBool lNot = \t -> t lFalse lTrue lXor :: CBool -> CBool -> CBool lXor = \u v -> u (lNot v) (lNot (lNot v)) -- You omitted some parens here! lXor' :: CBool -> CBool -> CBool lXor' = \u v -> u (v lFalse lTrue) (v lTrue lFalse) lXor'' :: CBool -> CBool -> CBool lXor'' = \u v -> u (lNot v) (v) lXor''' :: CBool -> CBool -> CBool lXor''' = \u v -> u (lNot v) v }}} So it all seems fine to me. I'll close as invalid but do re-open if you disagree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 00:06:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 00:06:54 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.b270c1a2b4a5e01416f2f1949b4a04c1@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by ezyang): So, I finished the `InstMap` implementation, and was about to wire up it with `InstEnv` when I realized there is one more thing to implement. You see, if the template variable doesn't match, the instance lookup code will TRY AGAIN to unify, this time properly unifying all variables and not just matching template variables, in order to provide the list of non- matching but unifying instances. So it looks like we'll need to implement this too, because otherwise the TrieMap lookup won't provide enough candidates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 00:57:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 00:57:48 -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.2b9f5987e8a05f78d3413448085afe27@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Okay, I tried running it under strace: the `write` from `hPutStrLn` is failing with `EIO`, which then gets turned into an exception, meaning `throwTo tid ExitSuccess` is never run. Since signals are handled in a new thread, if the signal handler raises an exception, it is reported to stderr (which, in this case, also fails with `EIO`), and the program continues to run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 02:00:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 02:00:36 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) Message-ID: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I used hprotoc to generate some code for Google protocol buffers. The QueryValue.proto file is attached. You can install hprotoc tool using cabal. then use ''hprotoc QueryValue.proto'' to generate code. Then create a minimal cabal file. ''cabal init -m --is-library -n'' Then if you build it with '''optimization enabled''', the build will fail ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_sEMq{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 59242 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 02:03:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 02:03:37 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.e8c479d2b01db759d34101b72a17923c@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new 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 play a little with generated code. The bug appears to be related to the type QueryValue.QueryValue.PropertyQueryValue being instance of Eq. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 06:58:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 06:58:05 -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.84a0f22418d3bbab056af412646a6444@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nakal): So the problem is that the exception that tries to output the cause to stderr also runs in the same problem as my trap function. Probably, this is not an intended behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 08:35:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 08:35:16 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.0f6a0da0c68ebe624f814928c92dbe6c@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new 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 simonpj): What happens if you follow the advice and increase `-fsimpl-tick-factor`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 10:08:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 10:08:48 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.6d575e9e3aa05367db9a1ae0d17dd255@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: AMP, Operating System: Unknown/Multiple | report-impact Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D510 -------------------------------------+------------------------------------- Comment (by hvr): Fyi, here's an attempt at updating/reviving the `haskell2010` package: http://git.haskell.org/packages/haskell2010.git/commitdiff/refs/heads/wip/T9590 but it's unsatisfying at this moment; as expected, `do`-syntax still refers to the `base`-version of the `Monad`-class, so you need to use `-XRebindableSyntax` and be careful to bring into local scope whatever functions are needed for syntax desugaring. Maybe we can improve the alternative-Prelude support in GHC 7.12 to allow a more seamless `-XRebindableSyntax` support which is less brittle, and allows to better emulate a strict `haskell2010` mode, which only requires to select the respective `-XHaskell....` flag for the language-part, and the respective `Prelude`-providing library-package instead of `base`, and would then drop you into a (reasonably) strictly standard-conforming language+std-library environment... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 12:08:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 12:08:19 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.91d2b0b2eb1587d13ad104c1137a04e6@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHCi crash | (amd64) Blocked By: | Test Case: Related Tickets: #7103, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): Replying to [comment:4 rwbarton]: > Use Linux? :) > Sorry, I have no Windows experience and no access to a Windows machine. I hope that was not offensiwe (although I feel it was). We cannot convert all the people we address the software to use Linux, can we? Additional I thought GHC is ment to be serious - cross-platform compiler, so I think solving this bug is somewhat important for everybody. We've got some windows expirence and people that can help you (but they are not haskellers) additional I can provide you any time remote machine on Amazon with everything configured - you could connect to it and check the things out. We will help you as much as we can also - what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 12:17:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 12:17:14 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.f7214be24e360957d4d43f64450ebc1a@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: AMP, Operating System: Unknown/Multiple | report-impact Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D510 -------------------------------------+------------------------------------- Comment (by hvr): Even something like `{-# LANGUAGE RebindableSyntax=haskell2010:Prelude.Syntax -#}` would already be an improvement with the following semantic: - desugaring like `-XRebindableSyntax`, - *but* rather than the local scope, only what's exported by the `Prelude.Syntax` module (from the `haskell2010` package) is used for desugaring, - and `Prelude.Syntax` can be a hidden module of the `haskell2010` package (to avoid polluting the module namespace) This could allow (maybe) to write a simple shell-script wrapper `ghci2010` (or `ghc2010`) in the style of {{{#!bash #!/bin/sh ghci -XHaskell2010 \ -hide-all-packages -package haskell2010 \ -XRebindableSyntax=haskell2010:Prelude.Syntax $* }}} This is similar to the `{-# LANGUAGE Prelude=AlternatePrelude #-}` idea we were floating recently, but also takes into account desugaring. NB: this doesn't solve the issue of packages compiled against `base` and `haskell2010` to have diverging typeclass hierarchies. But I don't think we can solve that without a significant amount of complexity. I'd rather suggest to instead have packages actively support `haskell2010` (maybe as Cabal configuration option via flags, or via hs2010-compat-layer packages -- not sure yet which is best) for those few packages where there's enough demand to (like e.g. something like `containers`). My main motivation for a `haskell2010` package is to have a reference implementation for the Haskell 2010 report (which can be useful for teaching, or for being able to compile some ancient "pure" Haskell2010 code with the latest GHC), rather than having full Hackage compatibility... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 12:34:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 12:34:42 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.f60d90ff72b8f4be17010c8711e621c2@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, and that is indeed a pain. Perhaps we should ''always'' do unification, which generalises matching, and distinguish the match cases post-hoc. Re the key thing, I think we may just want to keep (key,value) pairs at the leaves, rather than just values. Better than reconstructing the key from the tree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 12:47:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 12:47: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.75f0f06d9ca52a9b590d29358dbaf2f4@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: merge Priority: highest | 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm not sure this is right yet. '''First''' * For some reason `can_eq_nc'` only calls `can_eq_wanted_app` in the wanted/derived case. * That means that `try_decompose_app` cannot assume that its arg types are flattened. But `try_decompose_nom_app` and `try_decompose_repr_app` seem to assume that the type ''is'' flattened. The simple thing would be to rename `can_eq_wanted_app` to `can_eq_app`, and call it in all cases. '''Second'''. In your new `try_decompose_repr_app` you fail if either is an `AppTy`. But what about {{{ f a ~R g f a }}} where `g` flattens to `N`, a newtype {{{ newtype N f a = MkN (f a) }}} Then the flattened version will be {{{ f a ~R N f a }}} and that is certainly soluble. '''Third'''. What about {{{ a ~ f a }}} where `f` flattens to `N2` and {{{ newtype N2 a = MkN2 a }}} At the moment we will miss this altogether. We want an invariant that a representational `CTyEqCan` has a right-hand side that is not a newtype application. And we need to ensure that the invariant holds. So this really doesn't look good yet. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 12:48:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 12:48:58 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.cfc58ae74e5aab3e16bbc6e7078ff83e@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: -------------------------------------+------------------------------------- Comment (by pacak): Did you got my email? Can I get any other extra information for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 13:30:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 13:30:38 -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.45185fa81eb144c43d9bb05b06c60918@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: merge Priority: highest | 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:9 simonpj]: > I'm not sure this is right yet. Of course you're right. The difference in treatment between wanted/deriveds (where we flatten) and givens (where we don't) here is inherited from before my patch. Do you know why this was the case? Regardless, it does seem flattening is always necessary in the representational case. New proposal: `try_decompose_repr_app` will recur to `canEqNC` iff 1. Either side is headed by a newtype, OR 2. Neither side is an `AppTy`. Should be able to tweak this today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 13:59:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 13:59:01 -0000 Subject: [GHC] #10084: Data.List should have a takeLastN function Message-ID: <048.f0dafb5c3e070eda7142960a32ff6c8d@haskell.org> #10084: Data.List should have a takeLastN function -------------------------------------+------------------------------------- Reporter: leonbaum2 | Owner: Type: feature | Status: new request | 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: | -------------------------------------+------------------------------------- A natural compliment to the `take` function that instead takes `n` elements from the end of the list rather than from the start would be very useful. I'm surprised it's not defined in base because it seems to be a common operation that is not trivial to define in an efficient way. See http://www.joachim- breitner.de/blog/600-On_taking_the_last_n_elements_of_a_list -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 14:22:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 14:22:47 -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.ce14d446f199499fb25a4a665a5725e6@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: merge Priority: highest | 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): No I can't remember why the inherited thing was done; but I think we can simplify it away anyway. Re new proposal, I'm worried about what happens if we have `f a ~ N b`, where N's data constructor is not in scope. Then the `tcTopNormaliseNewTypeNF_maybe` thing won't fire, and we'll drop back into the `AppTy` case.... infinite loop. It doesn't smell good... code is too tricky. You don't comment about '''Third''' above; but it's another bug waiting to happen, isn't it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 14:49:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 14:49:58 -0000 Subject: [GHC] #10084: Data.List should have a takeLastN function In-Reply-To: <048.f0dafb5c3e070eda7142960a32ff6c8d@haskell.org> References: <048.f0dafb5c3e070eda7142960a32ff6c8d@haskell.org> Message-ID: <063.7e327f1c469e08ec542580d5110fd703@haskell.org> #10084: Data.List should have a takeLastN function -------------------------------------+------------------------------------- Reporter: leonbaum2 | Owner: Type: feature request | 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: -------------------------------------+------------------------------------- Comment (by nomeata): Heh, nice to see my blog cited here :-) One could argue that obviously, when you do `takeLastN` on a list, you are using the wrong data structure. But we also have `last` and `isSuffixOf` in `Data.List`, and maybe leaving it out for that reason is too much patronizing... In general, I?m in favor of adding that function. Did you have a real, practical need for the function, or are you bringing this up for other reasons? If you want this to become real, I suggest you follow the process in https://wiki.haskell.org/Library_submissions, i.e. send your proposal to the libraries mailing list. Possible issues to consider in the proposal and following discussion: * What is a good name for this? * If we have `takeLastN`, do we need `dropLastN`? How would that be implemented? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 15:04:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 15:04:03 -0000 Subject: [GHC] #8546: Panic during cabal build with profiling enabled. In-Reply-To: <046.19ad90151657537b62338ee47b7c0085@haskell.org> References: <046.19ad90151657537b62338ee47b7c0085@haskell.org> Message-ID: <061.dc09b655a44b6c211ef25b5d6be47071@haskell.org> #8546: Panic during cabal build with profiling enabled. -------------------------------------+------------------------------------- Reporter: Mokosha | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: cabal Operating System: Windows | sandbox Type of failure: Compile-time | Architecture: x86 crash | Test Case: Blocked By: | Blocking: Related Tickets: #7056 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * related: 7056 => #7056 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 15:11:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 15:11:31 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.fbced0a450d568b4007c52a62f3ad8e2@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHCi crash | (amd64) Blocked By: | Test Case: Related Tickets: #7103, #10051, | Blocking: #7056, #8546 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * related: #7103, #10051 => #7103, #10051, #7056, #8546 Comment: (Adding related tickets.) Basically, the check for these debugging symbol sections is a real hack. See https://github.com/ghc/ghc/blob/master/rts/Linker.c#L4388-L4407 for the relevant code. GHC tries to ignore sections containing debugging information in its own linker code, but this has proven pretty painful for us in the long run, because MinGW/binutils changes mean we frequently hit sections we didn't know about before, so things like this fail (even though those sections are almost certainly harmless). I suspect the best thing to do honestly is remove this code, or at least rework it. It is probably better to add a message which is printed out when linked with `-debug` (and using a debugging runtime flag) about what unknown sections we found, instead of always erroring out when an unknown section is found like we do today. This fix would be pretty simple and also fix the root issue of most of the related tickets (since they're basically all dupes of different colors). If someone would submit a (tested!) patch, that would be excellent! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 16:04:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 16:04:11 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.2da60ba3f240e63ce7fd77e08435a721@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: ekmett Type: bug | Status: upstream Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): For the record, recent versions of conduit-extra provide a proper streaming solution, e.g.: http://hackage.haskell.org/package/conduit-extra-1.1.6.2/docs/src/Data- Conduit-Filesystem.html#sourceDirectory This is based on non-conduit-specific code available in streaming-commons: http://hackage.haskell.org/package/streaming-commons-0.1.9.1/docs/Data- Streaming-Filesystem.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 16:07:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 16:07:57 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.12014c94d6946f70723b1d0dd3eb80c0@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: bug | Status: upstream Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * owner: ekmett => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 16:24:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 16:24:18 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.2995aba6af0c4beb1825c3412bac5fe7@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: bug | Status: upstream Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): Reviewing your code, it looks incredibly similar to the code that I wrote in streaming-commons. I think it does make sense to include such a patch in directory, but that should likely be handled via a pull request there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 18:16:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 18:16: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.cf241864f702aec4881f6ec5c1facbcd@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new 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 raised it up to 1M(1000000). Did not help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 19:52:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 19:52:51 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws In-Reply-To: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> References: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> Message-ID: <060.96c71ffc0c145cb75a9be636334fb340@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #10063 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gershomb): Also c.f. the proposed law here, pending discussion and tweaking: https://www.haskell.org/pipermail/libraries/2015-February/024943.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 20:23:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 20:23:24 -0000 Subject: [GHC] #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt In-Reply-To: <050.8ec6823346e7fe6fc27e65a4900502d1@haskell.org> References: <050.8ec6823346e7fe6fc27e65a4900502d1@haskell.org> Message-ID: <065.bf8fa1772f7074538c26e0b3163d4707@haskell.org> #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T10019 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via 4e25dc631b9c26365b57d315655723f088480f7e). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 20:23:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 20:23:34 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.70cb5dea50aeedd59189699013a5037b@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Profiling | 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: | Blocking: Related Tickets: #9961 | Differential Revisions: Phab:D616 | Phab:D636 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via 1d401b4384b5f9c7429140320e1d0bc120172b8b). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 20:24:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 20:24:00 -0000 Subject: [GHC] #9930: By default, a source code without extension would get overwritten by executable on *nix In-Reply-To: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> References: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> Message-ID: <064.9573f8eb47024333af5d2159e437323e@haskell.org> #9930: By default, a source code without extension would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via ed4de443b31bc383cc7194bef75d27c3a487e8de). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 20:24:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 20:24:31 -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.397c5a4eafb1f117aa80aa88b8cc6de4@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 7.10.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: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via dfb6b9f8290ebed55636074cea53f583d3ce1134, 9970626658b427df5e189a97496d89df76043e47 & 976e420fb2a7fa8bf3a22bc56bda7d15d2d27930). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 20:49:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 20:49:38 -0000 Subject: [GHC] #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression (was: Too late for parseStaticFlags, error in ghci calling main after loading compiled code) In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.b3fdba1ed4e8c338baedf10c1a843522@haskell.org> #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 20:52:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 20:52:06 -0000 Subject: [GHC] #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.8cb7aaa7d9c6e9096ed803ad63785946@haskell.org> #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): The workaround is to move the body of main into another function, say f, have main simply call f, and in ghci call f rather than main -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 21:40:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 21:40:25 -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.1cc5d424fc755985da3cec6a5c295221@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | 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: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: goldfire => * priority: highest => high * differential: => Phab:D653 * resolution: fixed => * status: closed => new Comment: Sadly, Simon's comment:9 exposes some serious flaws in my approach here. Work in progress on the solution is at Phab:D653. (Happily, that solution will also fix #7788 and #8550.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 21:40:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 21:40:37 -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.5a18061ed9ea6f40a5476c885584a3ec@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | 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: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * priority: high => highest * differential: Phab:D653 => Comment: (As an aside the supplied patch now does enable us to build all of lens `unsafeCoerce` free.) @thoughtpolice, is this actually closed, or just had the current patch applied? I definitely support finding the "right" fix here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 21:40:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 21:40:58 -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.8f449631d46afe99698ad3bdcc951e3a@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Er, woops. I didn't mean to delete those changes. We commented at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 21:42:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 21:42: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.65424c4926de3b9dced54e0b4a992912@haskell.org> #10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | 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: indexed- valid program | types/should_compile/T10079 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Changes (by ekmett): * priority: highest => high * differential: => Phab:D653 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 21:42:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 21:42:45 -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.17931683d0cc632f65bd0bf97087a162@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: | Differential Revisions: Phab:D653 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: For what it's worth, the fix just merged in ''does'' fix the problem stated in the ticket, and it doesn't make any of the issues from comment:9 worse. There's just lots more room for improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 22:16:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 22:16:12 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.bd0490c59a615b837830badc71b315df@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pgj): What is the underlying hardware? Unfortunately I could not yet reproduce this problem on my Intel Core i5 (with amd64), but this might be because I do not have a 10.1-RELEASE-p5 installed on that machine. (That is a bit older 11-CURRENT instead.) However, I was able to observe the same problem on a Hyper-V instance with 10.1 -- but I am not still sure if this is due to the virtualization or the kernel itself. I have also tried it with the 11-CURRENT kernel and the 10.1 userland (libthr and libc) but I did not get any problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 22:16:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 22:16:21 -0000 Subject: [GHC] #10085: Type families cause wrapper types to disappear without cause Message-ID: <049.8088dd32745a98df109c0dbda15b61aa@haskell.org> #10085: Type families cause wrapper types to disappear without cause -------------------------------------+------------------------------------- Reporter: tathougies | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (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: | -------------------------------------+------------------------------------- I tried to summarize the bug in the title, but I'm absolutely at a loss to understand what's going on here. Here's the output of a GHCi session: {{{#!hs 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> :set -XTypeFamilies Prelude> type family Strange (f :: * -> *) ty where { Strange f ty = Maybe (f ty) } Prelude> newtype Identity a = Identity { runIdentity :: a } Prelude> newtype StrangeHolder f = StrangeHolder (f Int) Prelude> let x = Just (Identity 3) :: Strange Identity Int Prelude> :type x x :: Maybe (Identity Int) Prelude> StrangeHolder _ :: StrangeHolder (Strange Identity) :8:15: Found hole ?_? with type: Maybe (Identity Int) Relevant bindings include it :: StrangeHolder (Strange Identity) (bound at :8:1) In the first argument of ?StrangeHolder?, namely ?_? In the expression: StrangeHolder _ :: StrangeHolder (Strange Identity) In an equation for ?it?: it = StrangeHolder _ :: StrangeHolder (Strange Identity) Prelude> :type x x :: Maybe (Identity Int) Prelude> StrangeHolder x :: StrangeHolder (Strange Identity) :10:15: Couldn't match type ?Identity Int? with ?Int? Expected type: Maybe Int Actual type: Maybe (Identity Int) In the first argument of ?StrangeHolder?, namely ?x? In the expression: StrangeHolder x :: StrangeHolder (Strange Identity) }}} GHC reports that it is expecting the type `Maybe (Identity Int)` as the first argument to `StrangeHolder`. It also reports that `x` has type `Maybe (Identity Int)`, but when I go to put `x` into a `StrangeHolder`, GHC has seemingly gotten rid of Identity, and now expects `x` to be of type `Maybe Int`. I think this is a bug, since the `Identity` type seems to disappear without cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 12 23:05:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Feb 2015 23:05:46 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.100897e0cf405cbd8ec8812d60e7a460@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nakal): This is not a virtualized system and the segfaults are reproducible without any exceptions. Here comes some data about it: CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz (3503.51-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads real memory = 17179869184 (16384 MB) At work I have some other system, also running FreeBSD-10.1-RELEASE on a AMD 3-core processor with 8 GB RAM. It also segfaults. Notice: I also have actually some other race conditions with signals on FreeBSD/amd64 with GHC-compiled programs that happen in Xmonad and are described here: https://code.google.com/p/xmonad/issues/detail?id=576#c6start=100 I would like to add it to the bugtracker as a separate problem (I still don't know how to describe it precisely enough for a bug report, but I am almost sure it belongs here rather than the Xmonad bugtracker), but looking at all this, it appears to me that GHC-binaries have some more problems with signals and threads on FreeBSD/amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 03:34:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 03:34:41 -0000 Subject: [GHC] #10085: Type families cause wrapper types to disappear without cause In-Reply-To: <049.8088dd32745a98df109c0dbda15b61aa@haskell.org> References: <049.8088dd32745a98df109c0dbda15b61aa@haskell.org> Message-ID: <064.24226e00d5c198046b2ed7ea4db02549@haskell.org> #10085: Type families cause wrapper types to disappear without cause -------------------------------------+------------------------------------- Reporter: tathougies | 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 glguy): There may be other issues here, but a significant one is that you're partially applying a type synonym family. This check was missing in 7.8 but is fixed for 7.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 07:16:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 07:16:34 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.fff18f7d93fa2f40987a50d3a75260ce@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pgj): Thanks for the details. I will keep trying to reproduce the problem. Based on my past experiences, I still believe that the problem comes from the FreeBSD base system, not GHC itself -- in such situations, I usually do some bisecting between the (kernel + userland) revisions to see which commit might have introduced the bug. It may also happen (as you wrote above) that it is all about race conditions which may require a system fast enough to make them visible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 08:40:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 08:40:07 -0000 Subject: [GHC] #10085: Type families cause wrapper types to disappear without cause In-Reply-To: <049.8088dd32745a98df109c0dbda15b61aa@haskell.org> References: <049.8088dd32745a98df109c0dbda15b61aa@haskell.org> Message-ID: <064.04805d37a260e83e89495c12e7545afa@haskell.org> #10085: Type families cause wrapper types to disappear without cause -------------------------------------+------------------------------------- Reporter: tathougies | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: invalid | 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 simonpj): * status: new => closed * resolution: => invalid Comment: Yes, glguy is spot on: you cannot partially apply a type family. This was a bug in 7.8 and I have no idea what unpredictable consequences might occur if you do. If you can make your strange behaviour happen with 7.10 then let's look at it. I'm sorry about the bug in 7.8 which has wasted some of your time. I'll close this as invalid (our fault not yours), but do re-open if you can make something like this happen without partial application. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 09:11:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 09:11:32 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.3382480dc5e41bd4c262e4d1da8a3bfb@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pgj): All right, here is a more detailed backtrace, just for the record: {{{ #0 0x00000000004801d7 in generic_handler () #1 0x00000008014810d6 in handle_signal (actp=0x7fffffffa418, sig=2, info=0x10006, ucp=0x7fffffffa480) at /usr/src/lib/libthr/thread/thr_sig.c:238 #2 0x0000000801480ad5 in thr_sighandler (sig=2, info=0x10006, _ucp=0x7fffffffa480) at /usr/src/lib/libthr/thread/thr_sig.c:183 #3 #4 select () at select.S:3 #5 0x000000080147ce95 in __select (numfds=2, readfds=0x7fffffffa930, writefds=0x7fffffffa9b0, exceptfds=0x0, timeout=0x7fffffffa920) at /usr/src/lib/libthr/thread/thr_syscalls.c:561 #6 0x00000000004534f3 in fdReady () #7 0x0000000000458e54 in base_GHCziIOziFD_zdwa3_info () #8 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 09:18:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 09:18:39 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.f0f19fb48ccbc67b83f211a663b136d4@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: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, got it, but I'm just snowed under. It would be super-helpful to be able to reproduce your problem myself, if you were somehow able to boil your production code down into a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 13:41:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 13:41:50 -0000 Subject: [GHC] #10086: Disambiguate type variables using dictionaries Message-ID: <048.cac35c7214f40042d40752ae112a5b66@haskell.org> #10086: Disambiguate type variables using dictionaries -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: Other Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this code: {{{#!hs type family TF t type instance TF (Maybe a) = Maybe a class Id f where idTF :: TF f -> TF f instance Id (Maybe a) where idTF x = x g = idTF (Just 'c') }}} Definition of `g` is rejected due to ambiguity: {{{ Couldn't match expected type ?TF f0? with actual type ?Maybe Char? The type variable ?f0? is ambiguous Relevant bindings include g :: TF f0 (bound at T6018.hs:18:1) In the first argument of ?idTF?, namely ?(Just 'c')? In the expression: idTF (Just 'c') }}} There are two ways to proceed: 1. Introduce `Proxy` argument and disambiguate `f` with explicit type annotation. 2. With injective type families (coming Real Soon Now) we can declare `TF` as injective and this code will compile. That obviously won't work if `TF` is not injective. I think we could do better here. `idTF` is a type class function and when it is called GHC uses a concrete implementation from a dictionary. But notice that if we have the dictionary we could equally well use it to disambiguate `f`. In this example we call `idTF` with a `Maybe Char` argument, which means we are using `Id (Maybe a)` instance. Knowing this we could infer that `f` is `Maybe a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 15:40:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 15:40:21 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.07ddfe50055a1bb635c8a078ca4e4bd3@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nakal): I have various systems that crash. In fact, every system I try crashes reliably no matter how fast or slow it is. Here two Xeons of type: CPU: Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz (1800.04-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) real memory = 17179869184 (16384 MB) And then the AMD triple-core (which I mentioned above) which is probably not as fast as your i5: CPU: AMD Athlon(tm) II X3 460 Processor (3400.20-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 1 package(s) x 3 core(s) real memory = 8589934592 (8192 MB) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 15:49:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 15:49:00 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.36b749d0141c7f6d4d61c912425e02ad@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pgj): Yeah, I have also managed to reproduce the crash on my dual-core AMD C-50 netbook (with 10.1-RELEASE), which is probably much slower than all of these machines. In the meantime, I have contacted Kostik Belousov (kib@), who maintains {{{libthr(3)}}} these days, but unfortunately he could not yet reproduce the problem on any of his machines. Although, this might be because he runs 10-STABLE. Perhaps could you please try a recent revision of the {{{stable/10}}} branch and report if the problem still persists there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 15:57:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 15:57:09 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.ea76eb62d834a99f4755dd1950e1e330@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.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 | -------------------------------------+------------------------------------- Changes (by goldfire): * related: #8550 => #8550, #10079 Comment: Just had a chat with Simon about all of this. We resolved several things: 1. The plumbing I have installed (in Phab:D653), using `FlatM` is helpful, and it caught errors in `shortCutReduction`. 2. Having `FlatM` modify a `CtLoc` is wrong, as it means that a certain `CtEvidence` suddenly has a new depth. This makes no sense. 3. Simon was uncertain about the need to bump the stack depth in `rewriteEqEvidence`. But, after some thought, this is appropriate (in the non-reflexive case): `rewriteEqEvidence` is often called after some flattening, and it's quite possible that the flattening reduced some type families. We debated various schemes where we would bump only if the flattener did indeed reduce a type family (or newtype), and perhaps even bump by just the right number of reductions, but these didn't seem to work out. A central problem is what to do if we flatten, say, `Either (F a) (G b)` to `Either t1 t2`, where `F a` and `G b` took ''different'' numbers of steps to reduce. No handling of this scenario seemed adequate. So, we always bump (in the non-reflexive case). 4. `rewriteEqEvidence` checks for deriveds before reflexivity. These should be reversed. 5. The flattener will count reductions ''separately'' from the canonicalizer. This amounts to plan (2) in comment:13, where the flattener can take `-ftype-function-depth` steps during eager reduction. Then, regardless of the number of steps the flattener took, `rewriteEqEvidence` will bump only by one. So, the actual number of reductions possible is something like the product of the class stack depth and the type function depth. 6. Because of the point above, a programmer has no hope of setting these depths correctly when type families or newtypes reduce. Indeed, exactly when we hit a certain limit is quite likely to change between minor GHC releases. However, these limits are there only to prevent GHC from looping. Once a programmer has written their module, confirms that it compiles in finite time, it is safe just to disable these checks -- GHC will still never produce wrong code; it just might never produce any code at all. Thus, the new recommendation when a programmer hits these limits is just to disable the check. Disabling the check is infinitely more robust than choosing a new, arbitrary limit, likely to change between minor releases. 7. Setting the stack depths to 0 will serve as the marker for infinity. 8. There are other places where 0 means infinity, such as `st_max_ticks` in `SimplMonad.SimplTopEnv` and `TcValidity.TypeSize`. These should be abstracted into a new integer+infinity type, to go in `BasicTypes`. 9. `shortCutReduction` is utterly bogus, and it was a great surprise to Simon that the wheels haven't fallen off. We believe that this function must not be called at all during building GHC and in the testsuite. I will check this, and remove the function if it is unused. It can be fixed fairly easily. But as the name implies, it is simply an optimization. If it never triggers, then there's no reason to keep around taking up space. Simon conjectures that the reason it's not used is due to the new eager type family reduction in the flattener. 10. After all of this is done, it will be possible to move the newtype- unwrapping code into the flattener, with a depth check intact. The work above is expected to fix this ticket, #8550, and #10079. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 15:58:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 15:58:05 -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.ef03a8db87fdfe9b1ba5e9c71db2ef5e@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 -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #7788, #8550 Comment: See comment:14:ticket:7788 for a plan going forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 16:30:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 16:30:50 -0000 Subject: [GHC] #10086: Disambiguate type variables using dictionaries In-Reply-To: <048.cac35c7214f40042d40752ae112a5b66@haskell.org> References: <048.cac35c7214f40042d40752ae112a5b66@haskell.org> Message-ID: <063.449d4934a6327735b01165ef5fd730fa@haskell.org> #10086: Disambiguate type variables using dictionaries -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): > In this example we call idTF with a Maybe Char argument, which means we are using Id (Maybe a) instance. But you can't infer that because there could be another instance `TF (Either Int a) = Maybe a` that you can't see. Or put differently, adding a new (compatible) instance for a type family is not supposed to break any uses of that type family. If `TF` was a closed type family, then perhaps GHC could make this sort of inference. It amounts to checking injectivity "locally" for particular types as needed: i.e. check not that `TF x = y` has at most one solution for every `y`, but just for the particular `y` that is needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 17:24:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 17:24:43 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.eabf15fd24a0a5991b8af4a45deb5a92@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Comment (by redneb): So let me explain what the problem is. My patch modifies the module `Text.Read.Lex`. This module defines among other thinks a `ReadP` parser that is used to implement the `Read` instances of all integral types. The actual instances though, are given in `GHC.Read` (except for `Natural` of course). My patch works by providing an optimized version of an ''internal'' function of `Text.Read.Lex`. If we also want to provide a version of that function for `Natural`, then we need to import `GHC.Natural`. But this creates multiple import cycles, exactly because that module was designed to be a leaf module. Namely, all of the following imports of `GHC.Natural` are problematic: `GHC.Read`, `Data.Data`, `GHC.Exception`, `Data.Int`, and `Data.Word`. So now we have 3 options: 1. Use my patch as it is, without the `Natural` specialization. Remeber that the `Read Natural` instance relies on the `Read Integer` instance and it will benefit too from my patch. 1. Use a simple hs-boot file for `GHC.Natural`. 1. Break the cycle by moving stuff out of `GHC.Natural`. This requires extensive changes (just look at the list of offending imports above) and honestly, my patch is not the only thing in `base` that does not treat `Natural` as an equal to `Integer` right now; for example the `Show Integer` has an ad-hoc implementation that has not been extended for `Natural` (instead `Show Natural` relies on `Show Integer` again). Given all of the above, I think 2 is the best option here. I really don't like hs-boot files, but I do think that the way `Natural`s have been implemented and possible large scale changes to that, is largely unrelated to my patch and should be discussed separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 19:12:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 19:12:58 -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.b83f25c2ee547cd42bfdfc9377b79bea@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch 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: Phab:D654 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D654 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 19:25:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 19:25:27 -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.de96af2f0bb1560b50377f610f52efdc@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch 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: Phab:D654 -------------------------------------+------------------------------------- Comment (by ekmett): This probably belongs as an actual libraries@ discussion due to very broad impact and the fact that it silently changes semantics on code in surprising ways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 19:30:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 19:30:00 -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.c534084cfc4199f978d124f394a341a3@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch 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: Phab:D654 -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: thomie (added) Comment: The underlying problem has to do with how the strictness analyzer treats FFI calls (maybe just unsafe ones): `c_function >> y` is considered to be strict in `y`. I consider this to be a bug (as seen here: what if `c_function` has some externally visible effect?) but I'm concerned that fixing it might have bad effects on performance in other settings. I think it's effectively just luck that we don't see the same behavior with `hPutStrLn stderr s`: `hPutStrLn` is too complicated for the strictness analyser. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 19:30:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 19:30:54 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.63ef68b891a616fd1fbda3bd9a759144@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Prelude | 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: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 19:34:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 19:34:57 -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.6f95d30a5c68b1d0d4552f4039c2ee28@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch 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: Phab:D654 -------------------------------------+------------------------------------- Comment (by rwbarton): Anyways I should add that this behavior of `trace` is very surprising and should definitely be fixed. But if we're going to work around the underlying bug with a hack (which seems reasonable to me) it should be a hack that is targeted to the actual issue. For example, I imagine that some use of magic functions like `lazy` would probably get the job done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 20:58:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 20:58:30 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.ca0b2dd26f7f2ddef736b3c675875d9d@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nakal): I've built FreeBSD 10.1-STABLE (r278692) and I can confirm that the bug is gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 21:07:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 21:07:31 -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.0805cfa65a93b88d4153ee2fe6206b5d@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch 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: Phab:D654 -------------------------------------+------------------------------------- Comment (by thomie): My reasoning was: `withCString`, and in turn `debugBelch`, need the complete string to be present before printing can start. `hPutStrLn` on the other hand prints character for character. So it's not about `trace` being lazy or not, but how it handles (possibly infinite) lazy strings. There are some problems however: * with my patch, traceIO would handle lazy strings differently on non- Windows vs. Windows. * traceEventIO and traceMarkerIO still don't handle lazy strings. Both emit to the eventlog, for which (I'm guessing) the complete string needs to be ready as well . Maybe we should keep things the way they are. Although surprising, at least the story is consistent over all `trace` functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 21:15:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 21:15:14 -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.f56982d912b5d953e0e365150d32d94c@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch 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: Phab:D654 -------------------------------------+------------------------------------- Comment (by rwbarton): That's a separate issue to the one the original bug report was about, though. The surprising behavior is that `trace a b` can evaluate `b` before printing `a`, and if evaluation of `b` enters an infinite loop, `a` will never be printed at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 21:40:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 21:40:44 -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.100ca28db6ce9162271f969e0fdb37cf@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch 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: Phab:D654 -------------------------------------+------------------------------------- Comment (by thomie): I'm confused. The examples from the description and from comment:1 print `a` before evaluating `b` in `trace a b`, when `a` is some fixed string. The problems arise when `a` can not be evaluated in full. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 22:24:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 22:24:38 -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.a17749e93b76f07f974a3cd5836fd71b@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch 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: Phab:D654 -------------------------------------+------------------------------------- Comment (by simonpj): Thomie is right, and Reid is (very unusually) off the mark, unless I'm mistaken. `trace` really is defined (in `Debug.Trace` like this), just as the OP thought: {{{ trace :: String -> a -> a trace string expr = unsafePerformIO $ do traceIO string return expr }}} The call to `traceIO` really does happen before `expr` is evaluated. The culprit is `traceIO`: {{{ traceIO :: String -> IO () traceIO msg = do withCString "%s\n" $ \cfmt -> do -- NB: debugBelch can't deal with null bytes, so filter them -- out so we don't accidentally truncate the message. See Trac #9395 let (nulls, msg') = partition (=='\0') msg withCString msg' $ \cmsg -> debugBelch cfmt cmsg when (not (null nulls)) $ withCString "WARNING: previous trace message had null bytes" $ \cmsg -> debugBelch cfmt cmsg }}} I'm not quite sure what those calls to `withCString` are doing, but I think they are strict in the string. So if the message has bottoms in it (which is the case in this example) none of it will get printed. That is not really too bad; although it should be documented. After all, you can always write {{{ trace ("in: " ++ show n) $ trace ("out: " ++ show res) $ res }}} and now you should see the first message even if you get stuck on the second. My conclusion: fix the documentation. I'll add this to the documentation for `trace`: {{{ The 'trace' function evaluates the message (i.e. the first argument) completely before printing it; so if the message is not fully defined, none of it will be printed. }}} OK? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 23:08:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 23:08:49 -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.1a9394282c2fb7e6d542266993a612db@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch 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: Phab:D654 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7fdded4ed7e670e0c83d312b56a59b36c52913c9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7fdded4ed7e670e0c83d312b56a59b36c52913c9" Improve documentation of 'trace' See Trac #9795. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 23:10:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 23:10:05 -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.8a77daf91578a9fbc234e347b12baafa@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: merge 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: Phab:D654 -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => merge Comment: Let's merge the doc change to 7.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 13 23:20:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Feb 2015 23:20:51 -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.7dbdbdaf217b91f8d4239d7c1305422f@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: merge 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): * differential: Phab:D654 => Comment: > I'll add this to the documentation for `trace`: > {{{ > The 'trace' function evaluates the message (i.e. the first argument) completely > before printing it; so if the message is not fully defined, none of it > will be printed. > }}} > OK? > > Simon Ok. Perhaps add that comment to the top of the module instead, since it applies to all the functions in the module equally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 00:40:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 00:40:26 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.f813c2e82dd7f00cc2c19576aeef10bc@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pgj): That is great! So may I close this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 08:57:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 08:57:21 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.0f65fdf69e9ecc6be440a735e44920df@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nakal): Yes, it looks to me as it is indeed a bug in FreeBSD 10.1-RELEASE and has been fixed in a future release. Thank you for your help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 09:02:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 09:02:40 -0000 Subject: [GHC] #10080: Recusive IO actions crash with segmentation fault In-Reply-To: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> References: <044.cda582f66147bdb1f22a2728e40d3a30@haskell.org> Message-ID: <059.165886df91ee11ac29a45cf3053dbe61@haskell.org> #10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by pgj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 10:50:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 10:50:57 -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.aacab03bc2acce1bd7b91c58b0f76282@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:3 rwbarton]: > Okay, I tried running it under strace Did you try to diagnose this on FreeBSD, or did you do this on some other system, such as Linux? I am asking because if the problem appears on systems other than FreeBSD, I would like to recommend to change the "Operating System" field of the ticket to reflect that this issue is system independent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 14:18:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 14:18:58 -0000 Subject: [GHC] #10087: DefaultSignatures: error message mentions internal name Message-ID: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> #10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: feature | Milestone: request | Version: 7.8.4 Priority: normal | Operating System: Unknown/Multiple Component: Compiler | Type of failure: Other (Type checker) | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DefaultSignatures #-} class C a where reflexive :: a -> Bool default reflexive :: Eq a => a -> Bool reflexive x = x == x data D instance C D where -- /home/abel/play/haskell/bugs/DefaultSig.hs:10:10: -- No instance for (Eq D) arising from a use of ?Main.$gdmreflexive? -- In the expression: Main.$gdmreflexive -- In an equation for ?reflexive?: reflexive = Main.$gdmreflexive -- In the instance declaration for ?C D? }}} Error looks odd: The user has not written $gdmreflexive in his code. TODO: Better error message. Maybe this should just trigger a warning that method {{{reflexive}}} is undefined for instance {{{D}}} of {{{C}}}. Like when I remove the default method. {{{ /home/abel/play/haskell/bugs/DefaultSig.hs:10:10: Warning: No explicit implementation for ?reflexive? In the instance declaration for ?C D? }}} It seems the semantics of a default signature is that each instance *must* implement this method. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 14:36:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 14:36:31 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.d56681660193c85e2448619422d01169@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: juhpetersen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 15:28:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 15:28:48 -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.7bcaa39be2b02e2af8d4d880ed133a44@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | 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 rwbarton): * os: FreeBSD => Unknown/Multiple Comment: Indeed, I am testing on Linux. However, I don't understand why this behavior is unexpected. The thread in which the signal handler runs dies due to an uncaught exception from `hPutStrLn`, and so the `throwTo` is never reached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 15:57:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 15:57:12 -0000 Subject: [GHC] #10078: tcPluginStop of a type checker plugin is not called if an error occurs In-Reply-To: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> References: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> Message-ID: <062.73c7fc0cba66b6c50ef27138abd1fe9e@haskell.org> #10078: tcPluginStop of a type checker plugin is not called if an error occurs -------------------------------------+------------------------------------- Reporter: jbracker | Owner: jbracker Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by jbracker): * owner: => jbracker -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 16:00:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 16:00:11 -0000 Subject: [GHC] #10087: DefaultSignatures: error message mentions internal name In-Reply-To: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> References: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> Message-ID: <066.2122fe491d6c481075b143bf94d851a3@haskell.org> #10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): I agree that it's not a good idea to mention `$gdmreflexive` in the error message. But I don't think the error should be replaced by a warning. If there are no default signatures we don't get any errors or warnings: {{{ class C a where reflexive :: Eq a => a -> Bool reflexive x = x == x data D instance C D }}} So perhaps that's what we should do in this case, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 18:45:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 18:45:02 -0000 Subject: [GHC] #8309: traceEvent truncates to 512 bytes In-Reply-To: <045.248642a5e64e6b0cbed6adafd24ed179@haskell.org> References: <045.248642a5e64e6b0cbed6adafd24ed179@haskell.org> Message-ID: <060.96e70785548ff6687b63eb6b21d64543@haskell.org> #8309: traceEvent truncates to 512 bytes -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: eventlog Operating System: Unknown/Multiple | tracing Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #3874 | Test Case: | Blocking: | Differential Revisions: Phab:D656 -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * status: new => patch * differential: => Phab:D656 * related: => #3874 Comment: I made `traceUserMsg` call `postUserMarker` (renamed to `postUserEvent`), which does not have the truncation problem. See the commit message in Trac #9395 (d360d440) for a discussion about using null-terminated strings vs strings with an explicit length. I did not make any change here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 19:16:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 19:16:58 -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.ac7b4362260f05bcf589a9355bafeb85@haskell.org> #10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | 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): Did you try to catch the exception at hPutStrLn? Maybe I did something wrong, but I could not work around it. Can you paste some code, so I can verify this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 20:07:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 20:07:20 -0000 Subject: [GHC] #10088: Broken link in Data.Ix documentation Message-ID: <045.c09a70d4edcadc1d6fc72f15af94ca31@haskell.org> #10088: Broken link in Data.Ix documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.11 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The Haddock documentation for `Data.Ix` includes the following line: For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html#prelude-index. This link is dead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 20:48:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 20:48:58 -0000 Subject: [GHC] #10087: DefaultSignatures: error message mentions internal name In-Reply-To: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> References: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> Message-ID: <066.c23a02124f34a53961a634a3b52ea502@haskell.org> #10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by andreas.abel): I see. You get the error when using the default implementation. {{{#!hs test :: D -> Bool test d = reflexive d }}} {{{ No instance for (Eq D) arising from a use of ?reflexive? In the expression: reflexive d In an equation for ?test?: test d = reflexive d }}} I agree this would be the most consistent behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 21:53:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 21:53:04 -0000 Subject: [GHC] #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) In-Reply-To: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> References: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> Message-ID: <061.3870a7ad3e45cd255882093d0a6e0853@haskell.org> #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) ----------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Comment (by kgardas): New patch provided in Phab:D657 -- thanks to Simon Marlow for his comments in Phab:D640. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 14 22:07:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Feb 2015 22:07:42 -0000 Subject: [GHC] #9606: Improve outdated ghc-pkg cache warning In-Reply-To: <042.9c58fbc29cb9829bc37b485448322dc0@haskell.org> References: <042.9c58fbc29cb9829bc37b485448322dc0@haskell.org> Message-ID: <057.f084a6acdc611b0ceef39b5bf75d8ee2@haskell.org> #9606: Improve outdated ghc-pkg cache warning -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: ghc-pkg | 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:D658 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D658 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 00:20:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 00:20:35 -0000 Subject: [GHC] #9402: Vestigial external core code in genprimops In-Reply-To: <047.41ab882fa71501e8a7cbcb7207176a86@haskell.org> References: <047.41ab882fa71501e8a7cbcb7207176a86@haskell.org> Message-ID: <062.b247d7c12c206933a521ff3455ee9efe@haskell.org> #9402: Vestigial external core code in genprimops -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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:D659 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D659 Comment: Should be ok to delete for 7.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 00:21:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 00:21:16 -0000 Subject: [GHC] #9402: Vestigial external core code in genprimops In-Reply-To: <047.41ab882fa71501e8a7cbcb7207176a86@haskell.org> References: <047.41ab882fa71501e8a7cbcb7207176a86@haskell.org> Message-ID: <062.e77e8fc2eaf5218cb9c398309c4b89c9@haskell.org> #9402: Vestigial external core code in genprimops -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch 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:D659 -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 01:20:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 01:20: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.18d618a52c0a3fe5fce9ba1ade58b06a@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: 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 thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 10:24:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 10:24:18 -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.655232933f81c95cf6a1c296f709a91a@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: new 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:4 trommler]: > I'm stuck at a Cabal error message: > [...] Alright, compiling the respective `Setup.hs` files for all dependencies and singletons, I can now reproduce the issue on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 13:28:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 13:28:47 -0000 Subject: [GHC] #10089: feature: warn about unused data definitions (with typeclass instances) Message-ID: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> #10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature | Status: new request | Milestone: Priority: normal | 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: | -------------------------------------+------------------------------------- Let's consider an example: {{{#!hs -- M.hs: module M () where -- ghc knows about uselessness of those data D = D -- but doesn't about this: data E = E deriving (Show, Read) }}} '''ghc''' warns about useless '''D''', but not '''E''': {{{ $ ghc-7.8.4 -Wall -c M.hs -fforce-recomp M.hs:5:1: Warning: Defined but not used: type constructor or class ?D? M.hs:5:10: Warning: Defined but not used: data constructor ?D? }}} There is no way to refer to '''E''' type outside or call it's unstances, correct? I would expect no code should be generated for this module. '''ghc''' could also warn about defined, but not used instances for types, that are not exported. Some background on where those stray types come from: 1. programmer usually adds a set of data types into their program (say, 10-15 types to represent an AST) 2. then annotates them with 'deriving (Read, Show)' convenience instances 3. (months later) amends AST representation a bit and leaves leftover data types not used anywhere Does that make sense? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 15:36:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 15:36:03 -0000 Subject: [GHC] #10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8" Message-ID: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> #10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8" -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Build | Operating System: Unknown/Multiple System | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- While building ghc-7.8.4 for Fedora 22 (devel) I found that doing highly parallel make builds of ghc affects the ABI hash of base, etc. The threshold seems to be between -j8 and -j12, which likely changes the build order of some modules causes changes to ABI hashes. While it is not hard to workaround, it is not really nice so it would be good to track this down IMHO. I haven't seen this kind of issue since 7.4.2 anyway so it may be an indirect buildsystem "regression" with ghc-7.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 18:37:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 18:37:19 -0000 Subject: [GHC] #10091: Add configurable verbosity level to hpc executable Message-ID: <044.9bf53187879824adb106c81d41020873@haskell.org> #10091: Add configurable verbosity level to hpc executable -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Code | Operating System: Unknown/Multiple Coverage | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Right now `hpc markup` writes a notice for each module and for each index file: {{{ Writing: Module.hs.html Writing: hpc_index.html Writing: hpc_index_fun.html Writing: hpc_index_alt.html Writing: hpc_index_exp.html }}} That is a bit annoying when you have e.g. 100 modules. I propose to add `--verbosity` flag with possible values `0`, `1` and `2` (default `1`) and suppress the notice for verbosity level `0` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 18:37:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 18:37:51 -0000 Subject: [GHC] #10091: Add configurable verbosity level to hpc executable In-Reply-To: <044.9bf53187879824adb106c81d41020873@haskell.org> References: <044.9bf53187879824adb106c81d41020873@haskell.org> Message-ID: <059.fabf3bf4dec691ae2d6190337b89d6e4@haskell.org> #10091: Add configurable verbosity level to hpc executable -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | Status: new Priority: normal | Milestone: 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: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Yuras): * owner: => Yuras -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 18:54:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 18:54:34 -0000 Subject: [GHC] #10091: Add configurable verbosity level to hpc executable In-Reply-To: <044.9bf53187879824adb106c81d41020873@haskell.org> References: <044.9bf53187879824adb106c81d41020873@haskell.org> Message-ID: <059.f8a096f117b3529615e333e699ff76da@haskell.org> #10091: Add configurable verbosity level to hpc executable -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | Status: new Priority: normal | Milestone: 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: Related Tickets: | Blocking: | Differential Revisions: Phab:D660 -------------------------------------+------------------------------------- Changes (by Yuras): * differential: => Phab:D660 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 20:16:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 20:16:22 -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.49776cf9bdcab6400eec11c54576d992@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): Just wanted to update a little on my work. I had one week off and will have one more now, so things are slower than I wanted, otherwise here are how things going: 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 When you run first one, it will replace (almost) all failed test's actual output with expected one. Afterwards, you should run second script, which will review trivial cases and git-add them. Finally, the ones that are left were reviewed manually. Currently status is that few tests still fail upon validate, and few will probably become failing after rebase. Anyway, will finish the work quickly after I come back from Norway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 20:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 20:21:51 -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.6c695a1fdf9b54df736abbc6342a109a@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: merge 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: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6fa285d77bba2d391b5d2b3c3abe1f19d298483c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6fa285d77bba2d391b5d2b3c3abe1f19d298483c" Move comments about evaluating the message to the top of the module The remarks apply equally to all the functions here (Trac #9795) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 20:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 20:21:51 -0000 Subject: [GHC] #10072: Panic: generalised wildcards in RULES In-Reply-To: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> References: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> Message-ID: <061.7af74600dec65bd32a17a27380c2e12e@haskell.org> #10072: Panic: generalised wildcards in RULES -------------------------------------+------------------------------------- Reporter: thomasw | Owner: thomasw Type: bug | 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: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5ab7518f28e89515c73ff09acd48b5acab48b8a5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5ab7518f28e89515c73ff09acd48b5acab48b8a5" Improve typechecking of RULEs, to account for type wildcard holes This fixes Trac #10072. Previously the type-hole constraint was escaping to top level, but it belongs in the scope of the skolems bound by the RULE. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 15 22:46:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Feb 2015 22:46:01 -0000 Subject: [GHC] #10092: lex doesn't handle binary literals Message-ID: <050.36d0be4204ee95d5f9c78410dc1eb92c@haskell.org> #10092: lex doesn't handle binary literals -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc2 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 {{{lex}}} function from {{{Text.Read.Lex}}} (on which the {{{Read}}} instance for {{{Lexeme}}} is based) can't read binary literals on GHC 7.10.1-rc2: {{{ $ ghci -XBinaryLiterals GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help ?> 0b101010 42 ?> import Text.Read.Lex ?> read "0b101010" :: Lexeme *** Exception: Prelude.read: no parse }}} This should be a simple fix, but I'm not sure if this is the intended behavior or not, since {{{BinaryLiterals}}} isn't a part of the Haskell 2010 standard (and I'm not sure how closely {{{lex}}} adheres to that). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 02:44:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 02:44:58 -0000 Subject: [GHC] #10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8" In-Reply-To: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> References: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> Message-ID: <065.6de70378fde26cb81eae4d2adcd42f8a@haskell.org> #10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8" -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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 juhpetersen: Old description: > While building ghc-7.8.4 for Fedora 22 (devel) I found that doing highly > parallel make builds of ghc affects the ABI hash of base, etc. > > The threshold seems to be between -j8 and -j12, which likely changes the > build order of some modules causes changes to ABI hashes. > > While it is not hard to workaround, it is not really nice so it would be > good to track this down IMHO. I haven't seen this kind of issue since > 7.4.2 anyway so it may be an indirect buildsystem "regression" with > ghc-7.8? New description: While building ghc-7.8.4 for Fedora 22 (devel) I found that doing highly parallel make builds of ghc affects the ABI hash of base, etc. The threshold seems to be between -j8 and -j12, which likely changes the build order of some modules causing changes to ABI hashes. While it is not hard to workaround, it is not really nice so it would be good to track this down IMHO. I haven't seen this kind of issue since 7.4.2 anyway so it may be an indirect buildsystem "regression" with ghc-7.8? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 06:28:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 06:28:40 -0000 Subject: [GHC] #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS Message-ID: <042.a6da12ed13280b322366fdac32c894b2@haskell.org> #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime crash Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `libraries/base/configure` currently clobbers `CPPFLAGS` and `LDFLAGS` when `--with-iconv-includes` and `--with-iconv-libraries` are given, but really it shouldn't. I will soon submit a patch for this. Here's what I stumbled upon (TL;DR): This is somewhat related to #2933. I have libiconv installed in `/usr/pkg`, which is a non-standard path that `ld.so` normally doesn't search libraries for. So I built GHC with `CONF_GCC_LINKER_OPTS_STAGE{0,1,2}` set to `-Wl,-rpath,/usr/pkg/lib` so that GHC links executables with `RPATH` pointing to `/usr/pkg/lib`. The build went fine until it started using `ghc-stage2` and `haddock`: they were causing segfaults in `evacuate()` with a probability of about 70%, which suggested a heap corruption occuring somewhere. I tried rebuilding RTS with `-O0 -g`, changed various parameters for GC, etc. Nothing changed. Then I suddenly realized that `libraries/base/configure` was the root cause of the problem. Those `configure` scripts are executed with `LDFLAGS` being set to the value of `CONF_GCC_LINKER_OPTS_STAGE2`, which is `-Wl,-rpath,/usr/pkg/lib` in my case, but `libraries/base/configure` overwrites it to `-L/usr/pkg/lib` when `--with-iconv- libraries=/usr/pkg/lib` is given. On the other hand, `FP_SEARCH_LIBS_PROTO(iconv)` appends `-liconv` to `$LIBS` so it will be linked to any conftest executables that follow, including one which will be generated by `AC_CHECK_SIZEOF()`. The problem is that if libraries listed in `$LIBS` are in a non-standard path while rpath flags are missing (due to `LDFLAGS` being clobbered in this case), conftest executables cannot run even if they can be linked. And if anything goes wrong during `AC_CHECK_SIZEOF(T)`, it considers `sizeof(T)` as 0 unless `T` is known to be an existing type: {{{ ... checking for library containing iconv... -liconv checking for library containing locale_charset... none required checking size of struct MD5Context... 0 ... }}} This means `SIZEOF_STRUCT_MD5CONTEXT` gets defined to 0, `GHC.Fingerprint.fingerprintData` allocates 0 bytes on the heap, `MD5Init`/`Update`/`Final` corrupts the heap and then Bad Things will happen. I have found the problem on NetBSD/amd64 but I'm sure the same thing happens on every ELF platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 06:53:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 06:53:08 -0000 Subject: [GHC] #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS In-Reply-To: <042.a6da12ed13280b322366fdac32c894b2@haskell.org> References: <042.a6da12ed13280b322366fdac32c894b2@haskell.org> Message-ID: <057.ced1e0c4df989c48cd27c436823e836b@haskell.org> #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D663 -------------------------------------+------------------------------------- Changes (by PHO): * status: new => patch * differential: => Phab:D663 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 06:56:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 06:56:08 -0000 Subject: [GHC] #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS In-Reply-To: <042.a6da12ed13280b322366fdac32c894b2@haskell.org> References: <042.a6da12ed13280b322366fdac32c894b2@haskell.org> Message-ID: <057.d83088e19b56e209cc2f30750a157d0a@haskell.org> #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D663 -------------------------------------+------------------------------------- Comment (by PHO): Okay I submitted a code review to Phabricator. This is my first time using Phab so I hope I haven't made mistakes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 08:09:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 08:09:55 -0000 Subject: [GHC] #10092: lex doesn't handle binary literals In-Reply-To: <050.36d0be4204ee95d5f9c78410dc1eb92c@haskell.org> References: <050.36d0be4204ee95d5f9c78410dc1eb92c@haskell.org> Message-ID: <065.1043a9025bcb68ac816ad311551cc97d@haskell.org> #10092: lex doesn't handle binary literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | BinaryLiterals report-impact Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9224 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) * keywords: => BinaryLiterals report-impact * component: libraries/base => Core Libraries * related: => #9224 * owner: => ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 09:04:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 09:04:33 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.3d845931a3225b8ca5a1a0c0bf6aeb79@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.10.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 Tarrasch): I just opened to phabricator diffs, the first being about stack reification in the rts. The second is more of a vision and probably more interesting to check out, as it's features Stack Traces in Haskell-land. https://phabricator.haskell.org/D661 https://phabricator.haskell.org/D662 Though there is still a lot of work left it seems. Right now, the biggest show-stopper is that D662 depends on the libdwarf library which isn't portable. Peter knows (much) more about this. Peter, care to give an update? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 09:54:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 09:54:01 -0000 Subject: [GHC] #10094: Template Haskell cannot represent type wildcards Message-ID: <049.6629ff791e291b2d66323173df5c56f5@haskell.org> #10094: Template Haskell cannot represent type wildcards -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: GHC rejects Keywords: | valid program Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There does not appear to be a way for Template Haskell code to generate partial type signature wildcards. The type quasiquote `[t|_|]` results in `Wildcard not allowed`, and use in an expression quasiquote like `[|() :: _|]` results in `Exotic form of type not (yet) handled by Template Haskell _`. It would be useful if TH code could partially constrain the type of the expressions it was generating, without needing to determine the type completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 10:34:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 10:34:45 -0000 Subject: [GHC] #10087: DefaultSignatures: error message mentions internal name In-Reply-To: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> References: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> Message-ID: <066.3917f352e41226b29618179beda3872d@haskell.org> #10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): Simon, is there a good reason for `tc_default` in `TcInstDcls` to treat `DefMeth` so differently from `GenDefMeth`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 12:44:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 12:44:35 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.61586be81cb67d4149d83d596680bbb2@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: -------------------------------------+------------------------------------- Comment (by pacak): Emailed 10x smaller version. I'm still trying to untangle some dependencies to provide hs file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 15:26:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 15:26:14 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.2d8d9fe0a6ffcf5e9b81c2873d534ba1@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | 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: #9821 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Branch `wip/T9968`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 16:39:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 16:39:47 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.354ffda69981f6a0fea2d2f9d187d6e2@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: AMP, Operating System: Unknown/Multiple | report-impact Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D510 -------------------------------------+------------------------------------- Comment (by hvr): Agda seems to have support via pragmas to inform the compiler about desugaring primitives (citing https://pay.reddit.com/r/haskell/comments/2vzqqa/picking_your_prelude/comxs6z): > Agda has a nice mechanism for avoiding this problem. The compiler/typechecker uses various functions and constants that are not built in to the language: for instance rewriting requires `PropositionalEquality` and its `refl` constructor, and desugaring numerals requires knowledge of the natural number type and the `zero` and `suc` constructors. > > All of these are made known to the Agda system in the standard library with a pragma: {{{ {-# LANGUAGE BUILTIN REFL refl #-} {-# LANGUAGE BUILTIN ZERO zero #-} }}} > etc. > > It's then possible to completely throw out the standard library and replace it with one of your own by using these pragmas to tell Agda to use your definitions instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 16:49:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 16:49:11 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.b17611421021208b2cd3072980c1a998@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: AMP, Operating System: Unknown/Multiple | report-impact Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D510 -------------------------------------+------------------------------------- Comment (by nomeata): Nice finding. But what is their scope? Do they leak to other modules like instance declarations? What if there are conflicts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 17:25:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 17:25:35 -0000 Subject: [GHC] #9054: runghc- does not call ghc of the same version In-Reply-To: <048.09116779ce49b45664b7ce81fecc6578@haskell.org> References: <048.09116779ce49b45664b7ce81fecc6578@haskell.org> Message-ID: <063.ecfc085fe40045255f579b27f234ea7d@haskell.org> #9054: runghc- does not call ghc of the same version -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 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: Phab:D664 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D664 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 20:11:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 20:11:44 -0000 Subject: [GHC] #10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8" In-Reply-To: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> References: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> Message-ID: <065.e15962fcb73dd49bdeb5af5cb376410a@haskell.org> #10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8" -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9370 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by int-e): * related: => #9370 Comment: I could reproduce this with ghc-7.8.4 (for example, I obtained 3 different ABI hashes for the haskell98 package from building ghc 6 times, with -j1, -j4, -j8, -j12, -j16 and -j24). On the other hand, 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. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 16 22:34:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Feb 2015 22:34:00 -0000 Subject: [GHC] #10089: feature: warn about unused data definitions (with typeclass instances) In-Reply-To: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> References: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> Message-ID: <060.f916ba2001e82f9ee7b2daf87e9fa6c2@haskell.org> #10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | 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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Good idea. It would take a little work to implement, though. A bit of background. Unused defintions are reported by `RnNames.reportUnusedNames`, which in turn consults the accumulated defs (definitions) and uses in the global `tcg_dus`. This in turn is set mainly by `RnSource.rnSrcDecls`. The defs/uses field is of type `NameSet.DefUses`, a type synonym for `[DefUse]`. However, ''the list is supposed to be in dependency order'', as you can see from `NameSet.findUses`. Instance declarations are currently treated as defining nothing, but having a bunch of uses. This is a `(Nothing, uses)` pair in the `DefUse` terminology. But that means that anything mentioned in an instance is unconditionally treated as "used", with the effect you observe. To do it right we'd really want to give the instance decl some "defs" too. Consider {{{ instance Show T where show = g }}} It could get a `DefUse` like this: `(Just {Show,T}, {g})`. This expresses the idea that if `Show` or `T` were referenced somewhere else (or exported) then the instance declaration (and all the things it refers to, namely `g`) would be treated as used. Actually you'd really want "and" rather than "or": if `Show` ''and'' `T` are both referenced somewhere else then the instance declarationis used. The trouble is that we can't then give the `[DefUse]` in dependency order: an instance declaration might mention a function, which refers to another type, which is in the head of another instance declaration. The obvious thing to do would be to give up on the dependency-order claim of `[DefUse]` and just take its transitive closure as a relation. Not too hard. So: * Treat `DefUses` as an un-ordered relation, and use transitive closure to find uses. * Give an instance decl `I` a `DefUse` like `(used in head of I, used elsewhere in I)`. * Provide "and" semantics as well as "or" semantics for `DefUse`. Not a big project, and worthwhile. Any volunteers? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 07:27:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 07:27:50 -0000 Subject: [GHC] #10095: Migration guide says classP / equalP remain but they were removed Message-ID: <050.0321ecf8dcfc897240294d0c6541953e@haskell.org> #10095: Migration guide says classP / equalP remain but they were removed -------------------------------------+------------------------------------- Reporter: | Owner: wereHamster | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#template- haskell-2.10.0.0 Commit 57b662c3efd in template-haskell.git. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 08:14:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 08:14:44 -0000 Subject: [GHC] #10096: Top-level ./configure should accept and propagate --with-curses-{includes, libraries} to libraries Message-ID: <042.c3039c780bf240b53edd532cee07dad0@haskell.org> #10096: Top-level ./configure should accept and propagate --with- curses-{includes,libraries} to libraries -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Build | Operating System: Unknown/Multiple System | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: #7472 Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If curses is installed into some non-standard path, we currently have to say something like the following in `mk/build.mk`: {{{ libraries/terminfo_CONFIGURE_OPTS += \ --configure-option=--with-curses-includes=/somewhere/include \ --configure-option=--with-curses-libraries=/somewhere/lib }}} This is because the top-level `configure` does not accept nor propagate `--with-curses-{includes,libraries}` to libraries while it does so for iconv, gmp and libffi. It would be nice if curses were handled in the same manner. I will soon submit a patch for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 09:00:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 09:00:57 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.5f5f890a175a0623738f734fb178103f@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * status: upstream => closed * resolution: => fixed Comment: I've implemented a fix for the stack overflow at: https://github.com/haskell/directory/pull/17 For the streaming interface: please send a pull request with your changes. I'm going to close this ticket as resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 09:36:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 09:36:01 -0000 Subject: [GHC] #10096: Top-level ./configure should accept and propagate --with-curses-{includes, libraries} to libraries In-Reply-To: <042.c3039c780bf240b53edd532cee07dad0@haskell.org> References: <042.c3039c780bf240b53edd532cee07dad0@haskell.org> Message-ID: <057.a0608567f00698d6432c38742f350d77@haskell.org> #10096: Top-level ./configure should accept and propagate --with- curses-{includes,libraries} to libraries -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7472 | Blocking: | Differential Revisions: Phab:D665 -------------------------------------+------------------------------------- Changes (by PHO): * status: new => patch * differential: => Phab:D665 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 09:40:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 09:40:21 -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.e7c5189b92571930770a3aee1c1d41ca@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 PHO): * cc: PHO (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 10:08:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 10:08:43 -0000 Subject: [GHC] #10072: Panic: generalised wildcards in RULES In-Reply-To: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> References: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> Message-ID: <061.def4d3e6532f1f1f436ff2a4829708c7@haskell.org> #10072: Panic: generalised wildcards in RULES -------------------------------------+------------------------------------- Reporter: thomasw | Owner: thomasw Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/T10072 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T10072 Comment: I think I have fixed this. Probably worth merging to 7.10. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 10:45:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 10:45:13 -0000 Subject: [GHC] #10097: GHC 7.11 errors on dictionary casting tricks Message-ID: <048.8f23ddac1f59d9eb9f781d8548dab25c@haskell.org> #10097: GHC 7.11 errors on dictionary casting tricks -------------------------------------+------------------------------------- Reporter: heisenbug | 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: | -------------------------------------+------------------------------------- I am not saying this is a bug, it just seems to mess with techniques that assume white-box knowledge of GHC's dictionary-passing internals. So, I have this function (in the `gdiff` fork I am fooling around with): {{{ iFeelDirty :: (forall ts . List f ts => f t ts -> Con f t) -> (forall ts . IsList f ts -> f t ts -> Con f t) iFeelDirty = unsafeCoerce }}} It compiles perfectly before 7.11, but now I get: {{{ src/Data/Generic/Diff/Effectful.hs:139:14: No instance for (List f ts3) The type variable `ts3' is ambiguous Relevant bindings include iFeelDirty :: (forall ts. List f ts => f t ts -> Con f t) -> forall ts. IsList f ts -> f t ts -> Con f t (bound at src/Data/Generic/Diff/Effectful.hs:139:1) In the expression: unsafeCoerce In an equation for `iFeelDirty': iFeelDirty = unsafeCoerce }}} For reference, this is the file I am looking at: https://github.com/ggreif/gdiff/blob/97b13e2dca0c35c2c53d5430f6f0700dc89938ec/src/Data/Generic/Diff/Effectful.hs#L138 Looks like the old trick (also used by ekmett's `reflection` lib?) fails to deliver. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 12:31:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 12:31:22 -0000 Subject: [GHC] #10087: DefaultSignatures: error message mentions internal name In-Reply-To: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> References: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> Message-ID: <066.39a244899893abf9d378ce4cceb105f3@haskell.org> #10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:3 dreixel]: > Simon, is there a good reason for `tc_default` in `TcInstDcls` to treat `DefMeth` so differently from `GenDefMeth`? No there isn't. See `tc_default` in `tcMethods` in `TcInstDcls`. * For polymorphic default methods, `DefMeth`, we generate ''typechecked'' `HsSyn Id`; see `Note [Default methods in instances]`. * For generic default methods, `GenDefMeth`, we currently generate ''renamed'' `HsSyn Name`, and then feed it to the type checker. * For user-written methods, `NoDefMeth`, we obviously just typecheck what the user wrote. I think it'd be pretty simple to instead treat `GenDefMeth` more like `DefMeth`. It might be a bit more code, but we'd get decent error messages. Do you think you could do that? I can advise. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 13:09:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 13:09:58 -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.32d769fe608e3040cd589a68cea82660@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: new 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Did you report a cabal bug for comment:4? That looks independent from this bug or from singletons. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 13:31:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 13:31:55 -0000 Subject: [GHC] #10095: Migration guide says classP / equalP remain but they were removed In-Reply-To: <050.0321ecf8dcfc897240294d0c6541953e@haskell.org> References: <050.0321ecf8dcfc897240294d0c6541953e@haskell.org> Message-ID: <065.5c95d7be634d57fcce05625d4ba81bb2@haskell.org> #10095: Migration guide says classP / equalP remain but they were removed -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | 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 goldfire): * status: new => closed * resolution: => invalid Comment: Yes, they were removed for a stretch, but they were put back in after complaints. As far as I can see, `classP` and `equalP` are in the 7.10 release candidates. Please reopen if you think I've missed something. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 13:43:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 13:43:46 -0000 Subject: [GHC] #10097: GHC 7.11 errors on dictionary casting tricks In-Reply-To: <048.8f23ddac1f59d9eb9f781d8548dab25c@haskell.org> References: <048.8f23ddac1f59d9eb9f781d8548dab25c@haskell.org> Message-ID: <063.98b99a96f1bf627ac353871bf68e346c@haskell.org> #10097: GHC 7.11 errors on dictionary casting tricks -------------------------------------+------------------------------------- Reporter: heisenbug | 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: -------------------------------------+------------------------------------- Comment (by goldfire): I don't like that there's been a typechecker regression here, but this doesn't seem like an outright bug to me. The one bit I'm quite unsure of is the eta-contraction... and my reasoning-about-higher-rank-eta- contracted-functions neuron seems to be enjoying the snow day here. So I'll eta-expand: {{{ iFeelDirty x = unsafeCoerce x }}} Now, I can see why your error appears. When you say `x`, GHC will try to instantiate the implicit parameters of `x`, namely `ts` and `List f ts`. But, GHC has no guidance as to what these should be, because it can't glean anything useful from `unsafeCoerce`. Some more type annotations might be helpful, as might be newtype wrappers to accurately control what you're `unsafeCoerce`ing. So, I have two conclusions: * I'm happy enough with an error in the eta-expanded version, but I agree that the eta-contracted one should probably work. * I don't think this bug shows up a problem with the dirty dictionary- casting trick. That should still be valid. It's just a typechecker behavior change, which (I believe) could be overcome with more types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:03:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:03:17 -0000 Subject: [GHC] #3628: exceptions reported to stderr when they propagate past forkIO In-Reply-To: <045.1fd3d7941c00c82461fdc1db8e459688@haskell.org> References: <045.1fd3d7941c00c82461fdc1db8e459688@haskell.org> Message-ID: <060.3f15e9c5038c451892871d72f0bf0648@haskell.org> #3628: exceptions reported to stderr when they propagate past forkIO -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.10.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 snoyberg): * cc: core-libraries-committee@? (added) * failure: => None/Unknown Comment: I'm in favor of closing this issue: it doesn't not seem like something we are going to change at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:04:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:04:34 -0000 Subject: [GHC] #2123: implement waitForProcess using signals In-Reply-To: <047.96e17276f11f467a9162fc8e32a52352@haskell.org> References: <047.96e17276f11f467a9162fc8e32a52352@haskell.org> Message-ID: <062.6a72edf30898488ccda79c7f0c8ca9f6@haskell.org> #2123: implement waitForProcess using signals -------------------------------------+------------------------------------- Reporter: simonmar | Owner: snoyberg Type: task | Status: new Priority: lowest | Milestone: 7.12.1 Component: Core Libraries | 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 snoyberg): * cc: core-libraries-committee@? (added) * owner: ekmett => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:05:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:05:55 -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.ba5afb9e282c666cd79c98b99d07cbb6@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: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: core-libraries-committee@? (added) * owner: ekmett => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:08:30 -0000 Subject: [GHC] #3649: inconsistent exception between unix/windows for running non-existant program In-Reply-To: <045.38ca9e41e1ac2553ec6a5c6c46307813@haskell.org> References: <045.38ca9e41e1ac2553ec6a5c6c46307813@haskell.org> Message-ID: <060.b3e20536dbe41fcf681a384f5659fe34@haskell.org> #3649: inconsistent exception between unix/windows for running non-existant program -------------------------------------+------------------------------------- Reporter: duncan | Owner: snoyberg Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 6.10.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 snoyberg): * cc: core-libraries-committee@? (added) * owner: ekmett => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:17:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:17:38 -0000 Subject: [GHC] #3998: strace breaks System.Process(?) In-Reply-To: <046.25275139f38bce89419f17d420899256@haskell.org> References: <046.25275139f38bce89419f17d420899256@haskell.org> Message-ID: <061.e44a1aff23683bbf44fff28c8db89226@haskell.org> #3998: strace breaks System.Process(?) -------------------------------------+------------------------------------- Reporter: greenrd | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: core-libraries-committee@? (added) * owner: ekmett => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:18:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:18:10 -0000 Subject: [GHC] #5761: Getting stdout and stderr as a single handle from createProcess does not work on Windows In-Reply-To: <050.e9fa2e5a1b52616542ec334b8e4a4c3f@haskell.org> References: <050.e9fa2e5a1b52616542ec334b8e4a4c3f@haskell.org> Message-ID: <065.3892cfa6eddce6202335d0613b95deb0@haskell.org> #5761: Getting stdout and stderr as a single handle from createProcess does not work on Windows -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: core-libraries-committee@? (added) * owner: ekmett => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:18:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:18:22 -0000 Subject: [GHC] #7997: waitForProcess and getProcessExitCode are unsafe against asynchronous exceptions In-Reply-To: <046.52e563bbb1daefe1d44a7ec227a6dd7e@haskell.org> References: <046.52e563bbb1daefe1d44a7ec227a6dd7e@haskell.org> Message-ID: <061.f22815db00c7845c52aba027d25a5c29@haskell.org> #7997: waitForProcess and getProcessExitCode are unsafe against asynchronous exceptions -------------------------------------+------------------------------------- Reporter: dfranke | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: core-libraries-committee@? (added) * owner: ekmett => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:18:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:18:33 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.3f21a40b4717907a0d80603417490652@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: snoyberg Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | 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: Phab:D42 -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: core-libraries-committee@? (added) * owner: => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:18:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:18:47 -0000 Subject: [GHC] #8844: Pseudo terminal and process-1.2.0.0 In-Reply-To: <049.4e9c2e6d1c0aa3bbcf4607dd7d51c8fd@haskell.org> References: <049.4e9c2e6d1c0aa3bbcf4607dd7d51c8fd@haskell.org> Message-ID: <064.cae521e2d4574923b54a77d73cf0c2d5@haskell.org> #8844: Pseudo terminal and process-1.2.0.0 -------------------------------------+------------------------------------- Reporter: ksamborski | Owner: snoyberg Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: pty Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: core-libraries-committee@? (added) * owner: ekmett => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:18:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:18:53 -0000 Subject: [GHC] #9135: readProcessWithExitCode leaks when the program does not exist In-Reply-To: <044.d94b762093486fb03a7765d4a9e7d317@haskell.org> References: <044.d94b762093486fb03a7765d4a9e7d317@haskell.org> Message-ID: <059.078389727203580025eff0e2382adc50@haskell.org> #9135: readProcessWithExitCode leaks when the program does not exist -------------------------------------+------------------------------------- Reporter: luite | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 snoyberg): * cc: core-libraries-committee@? (added) * owner: ekmett => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:30:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:30:00 -0000 Subject: [GHC] #3649: inconsistent exception between unix/windows for running non-existant program In-Reply-To: <045.38ca9e41e1ac2553ec6a5c6c46307813@haskell.org> References: <045.38ca9e41e1ac2553ec6a5c6c46307813@haskell.org> Message-ID: <060.13b5d09bf4ec72b1b9c94ab999a68c96@haskell.org> #3649: inconsistent exception between unix/windows for running non-existant program -------------------------------------+------------------------------------- Reporter: duncan | Owner: snoyberg Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 6.10.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 snoyberg): * status: new => closed * resolution: => fixed Comment: Duncan, I've implemented a fix for this at: https://github.com/snoyberg/process/commit/2fe95e32adff6d03cd04e3cf0f6d99f66625b33c. I'm going to close this issue as resolved, if there is still a problem please reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:45:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:45:19 -0000 Subject: [GHC] #10097: GHC 7.11 errors on dictionary casting tricks In-Reply-To: <048.8f23ddac1f59d9eb9f781d8548dab25c@haskell.org> References: <048.8f23ddac1f59d9eb9f781d8548dab25c@haskell.org> Message-ID: <063.804744d25a1220ad8042ab3c85e637fe@haskell.org> #10097: GHC 7.11 errors on dictionary casting tricks -------------------------------------+------------------------------------- Reporter: heisenbug | 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: -------------------------------------+------------------------------------- Comment (by simonpj): A recent (somewhat obscure) change is that GHC actually does eta-expansion to make higher-rank types match up. That is often useful (i.e. makes more programs typecheck). And really it is confusing if eta-expansion can make a difference to type checking. So I'm disinclined to "fix" this. Or at least I'd require more motivation! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:47:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:47:47 -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.0ac66428892e0cbf52896a4e5924c49e@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: merge 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: -------------------------------------+------------------------------------- Comment (by jcpetruzza): I still think that being strict on the string is the wrong default for a function whose only purpose is debugging pure functions, and I don't quite see what the benefit of the current behaviour is. Simon's workaround works after the fact, when you already know that the problem might be `res` being bottom. When starting a debugging session, one doesn't always have a clear suspicion of the culprit. A good part of the usefulness of `trace` is giving you an indication that certain expression is actually being evaluated, even if the full string fails to be printed in full. The way I see it, in order to avoid problems with a strict `trace`, one should be more defensive and start using it as Simon indicates in a systematical way. Consider for example the following excerpt from the [[https://wiki.haskell.org/Debugging|wiki entry on debugging]]: A common idiom to trace a function is: {{{ #!haskell myfun a b | trace ("myfun " ++ show a ++ " " ++ show b) False = undefined myfun a b = ... }}} With the current behaviour, I believe this should really be: {{{ #!haskell myfun a b | trace "myfun " $ trace (show a ++ " " ++ show b) False = undefined myfun a b = ... }}} and/or an explanation on `trace` being strict and what could happen if `show a` or `show b` loop or have an infinite output. With a lazy `trace` all this goes away, making `trace` more powerful and easier to use. Perhaps there are very good reasons to keep `trace` strict, but I'm not aware of them... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 14:52:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 14:52:48 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.4b5f77254f97094f8d46b25c3846676d@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 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: -------------------------------------+------------------------------------- Comment (by simonpj): Just to add: I think Reid's comment:14 is spot on. The solution, I believe, is this: * Always read in unfoldings, etc, including with `-O`. (Possible exception: one-shot mode.) * Check the `-fignore-interface-pragmas` flag when considering inlining a function. So an `Id` would always contain its inlining; but at the ''usage sites'' we'd decide whether or not to use it. An extra test at every inlining, but there are already a lot of tests at inlining sites! This would be a good, small, contained project for someone. Volunteers? If it's mission-critical for anyone, please yell. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 15:18:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 15:18:50 -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.668052f38880a459c549e66ab6db6a6a@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, are you proposing to merge the current (incomplete) change to 7.10, leaving the "plan going forward" for 7.12? Or can you do it for 7.10? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 15:20:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 15:20:26 -0000 Subject: [GHC] #10095: Migration guide says classP / equalP remain but they were removed In-Reply-To: <050.0321ecf8dcfc897240294d0c6541953e@haskell.org> References: <050.0321ecf8dcfc897240294d0c6541953e@haskell.org> Message-ID: <065.5e0123ac9b6e8fce38b06c3b2afb8310@haskell.org> #10095: Migration guide says classP / equalP remain but they were removed -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | 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 wereHamster): My bad. It would seem that http://git.haskell.org/packages/template- haskell.git is no longer the place where TH development takes place, and I was looking there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 15:20:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 15:20:52 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.7775ebe276cd08b2f87a8cce2fbc7930@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | 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: #9821 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): FYI Pedro is actively working on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 15:24:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 15:24:32 -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.bec5fe91372fd070cf3cf9bcb91491dd@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 a little squeezed up against the ICFP deadline, on Feb. 27. The plan going forward is a solid half-day's work, I think, which I may not have. When is RC3 due to be cut? I can try to get to it sooner, but having a few days of March would make a big difference for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 15:28:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 15:28:08 -0000 Subject: [GHC] #10098: Refactor wild card renaming Message-ID: <052.6e4b7f96cd090e4532413a4e30b58f3a@haskell.org> #10098: Refactor wild card renaming -------------------------------------+------------------------------------- Reporter: | Owner: thomasw thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #9922 Test Case: | Blocking: | Differential Revisions: Phab:D613 | -------------------------------------+------------------------------------- Imported from #9922, comment #5: --------------------- Austin: let's merge this to 7.10.1. Thomas: I'm not very happy with the way that wild-card error reporting is done. I think we discussed this before, but left it on one side until it was all working. Which it now is. What I suggest is this: Things I dislike: * I dislike the `checkParitalTypeSignature` and `checkNoPartialType` stuff in `RdrHsSyn`. The only checks that belong in `RdrHsSym` are ones that prevent you building a syntax tree at all. All other checks are best done later, when good error reporting is easier, and you can recover from errors. * I particularly hate the `RnTypes.extractWildcards` stuff. It's like a whole extra renaming pass over the type, changing `HsWildCardTy` to `HsNamedWildCardTy` with an `Exact` `RdrName` in it. Yuk! Here is a possible plan: * Remove all the checking from `RdrHsSyn`, unless we can't build a syntax tree without it. * Collapse `HsWildcardTy` and `HsNamedWildcardTy` into one, with a boolean (or a `Named`/`Anonymous` flag) to distinguish. * Provide a specialised version of `rnLHsType`, perhpas `rnLHsTypeWithWildCards`, that does the inital pass to find the named wildcards and bring them into scope. This version is called in the places where you can have a type with wildcards, namely * `TypeSig` * `ExprWithTySig` * `rnHsBndrSig` * `rnLHsTypeWithWildCards` can work like this: 1. Collect all the named wildcards, and bring them into scope. This is a simple, ''pure'' function. 2. Call `rnLHsType`. When `rnLHsType` finds an anonymous wildcard, just make up a fresh name, rather than looking it up. 3. Collect all the wildcards (named or anonymous) to get a `[Name]`; again a pure function 4. Return the renamed type and the wildcard names That makes three passes, but each is simple. In fact (1) and (4) could perhaps be the same function, with a boolean flag to say which wildcards to return. * All this means that when `rnLHsType` is called directly (not via `rnLHsTypeWithWildCards`) on a type like `_ -> Int`, it will succeed, generateing a fresh name for the `_`. That's fine. In `tc_hs_type` we will find it is not in scope, so we can say "Unexpected wildcard in type", and the enclosing location information will nail down the details. * There are, I think, three places where `HsWithBndrs` is used: `HsDecls.HsTyPats`, `HsDecls.RuleBndr`, `HsPat.SigPatIn`. In the latter two I think that wildcards should be legal; in the first not so. (Do you have tests for all three?) So the caller of `rnHsBndrSig` should check for empty wildcards in the cases where there shouldn't be any. I this this is just in type/data family patterns. I have not throught throught the extra-constraints wild card, but I think a similar plan should work. Does this make sense? Might you do it? (To HEAD, of course.) Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 18:29:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 18:29:44 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.3a6d8b3233f0040d5c7ee3d766849e6f@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: #7056, #8546 | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- * architecture: x86_64 (amd64) => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 17 21:24:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Feb 2015 21:24:58 -0000 Subject: [GHC] #9588: Add `MonadPlus {IO, Either e}` and `Alternative (Either e)` instances In-Reply-To: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> References: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> Message-ID: <057.310b5d912c48f0c3b850c0336946bdf1@haskell.org> #9588: Add `MonadPlus {IO,Either e}` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): We should at least split this up into the easy and the hard cases and bite off the `IO` instances for now, and we can explicitly punt on the `Either e` case until someone comes up with a better idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 05:23:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 05:23:16 -0000 Subject: [GHC] #9959: removeDirectoryRecursive should not follow symlinks In-Reply-To: <045.bc668a211256e76b58f6ce62e4042a84@haskell.org> References: <045.bc668a211256e76b58f6ce62e4042a84@haskell.org> Message-ID: <060.92258a6982c11eb152716221f0c7d404@haskell.org> #9959: removeDirectoryRecursive should not follow symlinks -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: Component: | Version: 7.11 libraries/directory | 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 Rufflewind): Turns out the documentation was misleading, though [https://github.com/haskell/directory/issues/15 in some odd cases it does traverse symlinked directories]. The former documentation error has been fixed in [https://github.com/haskell/directory/commit/db88005a736f88ac212152d69ce4002f4d852219 db8800]. The latter bug should be fixed in [https://github.com/haskell/directory/pull/16 this pull request]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 05:23:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 05:23:58 -0000 Subject: [GHC] #9959: removeDirectoryRecursive should not follow symlinks In-Reply-To: <045.bc668a211256e76b58f6ce62e4042a84@haskell.org> References: <045.bc668a211256e76b58f6ce62e4042a84@haskell.org> Message-ID: <060.9a4e015b2e85faae57ae2844717bf109@haskell.org> #9959: removeDirectoryRecursive should not follow symlinks -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: | Version: 7.11 libraries/directory | 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 Rufflewind): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 09:56:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 09:56:04 -0000 Subject: [GHC] #10086: Disambiguate type variables using dictionaries In-Reply-To: <048.cac35c7214f40042d40752ae112a5b66@haskell.org> References: <048.cac35c7214f40042d40752ae112a5b66@haskell.org> Message-ID: <063.2d736f3a79e1cb1a6933f1aa180a2413@haskell.org> #10086: Disambiguate type variables using dictionaries -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => invalid Comment: Looks like you're right. I'll close this as invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 13:28:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 13:28:22 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.9fd80cd58b6fc60e64c3ba9e3d75706f@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: #8634 | -------------------------------------+------------------------------------- Comment (by jstolarek): I've just run into this problem trying to run this toy example from [[https://wiki.haskell.org/Type_arithmetic|Haskell Wiki]]: {{{#!hs data Zero data Succ a class Add a b ab | a b -> ab, a ab -> b instance Add Zero b b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} {{{ Illegal instance declaration for ?Add (Succ a) b (Succ ab)? The liberal coverage condition fails in class ?Add? for functional dependency: ?a b -> ab? Reason: lhs types ?Succ a?, ?b? do not jointly determine rhs type ?Succ ab? In the instance declaration for ?Add (Succ a) b (Succ ab)? }}} Interestingly, replacing empty data declarations of `Zero` and `Succ a` with data kinds makes the code compile: {{{#!hs data Nat = Zero | Succ Nat class Add a b ab | a b -> ab, a ab -> b instance Add Zero b b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} Why with empty data types this is wrong but with promoted types everything is fine? Also, HEAD complains about redundant constraint: {{{ Redundant constraint: Add a b ab In the instance declaration for ?Add ('Succ a) b ('Succ ab)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 14:25:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 14:25:12 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.4b72524e1293d7fafdc57827748fb375@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: -------------------------------------+------------------------------------- Comment (by simonpj): OK, I looked at the 10x smaller version. Can you attach it to the ticket? (180kb is ok I think.) I could do so, but do not want to upload sensitive info. I have learned some things (see below). But to explore solutions I really do need a reproducible test case. So if you untangle dependencies that would be really helpful. It's hard for me to make more progress without that. E.g. I want to see the code just before strictness analysis. I want to see the code and strictness for `Trader.Order.Logging.$wa`, which is in a different module. The rest of this is notes for me or other hackers, to record what I have learned. I'm certain that difficulty is to do with '''reboxing''' (c.f. #2289). I see a function `processManualOrders` that I believe looks somethign like this (before strictness analysis) {{{ pma _ p q r = let help x v = case select_deep_field_of p of True -> ...(help x v')... False -> log_fn x -- log_fn is lazy in x in help p r }}} So the `help` function is not strict in `x`. But `pma` is strict in `p` because of the `(select_deep_field p)` in `help`. Sadly that means that `p` is passed to `help` in ''boxed'' form (since `help` is lazy), but is passed to `pma` in ''unboxed'' form (since `pma` is strict). The result is that `p` is re-boxed in the worker for `pma`. And `p` is a record with many tens of fields. Various things would help here: * Running the static argument transformation on `help` would solve the problem completely. * It probably does not make sense to do worker/wrapper on records with huge numbers of fields. We end up passing arguments in memory anyway, just on the stack instead of in the heap. And the reboxing penalty is large. * In `Demand.bothUse` I see {{{ bothUse (UProd {}) (UCall {}) = Used -- bothUse (UProd {}) Used = Used -- Note [Used should win] bothUse Used (UProd ux) = UProd (map (`bothMaybeUsed` useTop) ux) bothUse (UProd ux) Used = UProd (map (`bothMaybeUsed` useTop) ux) bothUse Used _ = Used -- Note [Used should win] }}} Note that commented out line. If `Used` really did win, I think that most of this fruitless work would go away. But it's delicate and I'm sure the commented out line was commented out for a reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:25:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:25:42 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.2f16caf42e759c347495a7d67c23441b@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: #8634 | -------------------------------------+------------------------------------- Comment (by goldfire): My guess is that !PolyKinds is causing trouble in the not-promoted case. Do you have !PolyKinds enabled? Try running with `-fprint-explicit-kinds`. But, the "redundant constraint" warning is almost certainly wrong. I would post that as a separate bug, which we should try to fix by 7.10, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #3874: GHC.Exts.traceEvent segfaults In-Reply-To: <042.5001be7fcc4218b1286fd5d57d850c3a@haskell.org> References: <042.5001be7fcc4218b1286fd5d57d850c3a@haskell.org> Message-ID: <057.44159b11c78022cbc5c9e98a0e03751d@haskell.org> #3874: GHC.Exts.traceEvent segfaults -----------------------------------+-------------------------------- Reporter: cjs | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: fixed | Keywords: event, eventlog Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: -----------------------------------+-------------------------------- Comment (by Austin Seipp ): In [changeset:"a82364c9410d35fa9cb5031d553212267c3628c5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a82364c9410d35fa9cb5031d553212267c3628c5" Don't truncate traceEvents to 512 bytes (#8309) Summary: Don't call postLogMsg to post a user msg, because it truncates messages to 512 bytes. Rename traceCap_stderr and trace_stderr to vtraceCap_stderr and trace_stderr, to signal that they take a va_list (similar to vdebugBelch vs debugBelch). See #3874 for the original reason behind traceFormatUserMsg. See the commit msg in #9395 (d360d440) for a discussion about using null-terminated strings vs strings with an explicit length. Test Plan: Run `cabal install ghc-events` and inspect the result of `ghc-events show` on an eventlog file created with `ghc -eventlog Test.hs` and `./Test +RTS -l`, where Test.hs contains: ``` import Debug.Trace main = traceEvent (replicate 510 'a' ++ "bcd") $ return () ``` Depends on D655. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D656 GHC Trac Issues: #8309 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #9094: remove RAW_CPP In-Reply-To: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> References: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> Message-ID: <060.37a07e9f29c6afc31cc45d75160c9834@haskell.org> #9094: remove RAW_CPP -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 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: #8683 | Blocking: | Differential Revisions: Phab:D648 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"555eef1d0fb5a7fd07971c1201b3c520f01125d4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="555eef1d0fb5a7fd07971c1201b3c520f01125d4" Remove RAWCPP_FLAGS (Task #9094) Reviewers: carter, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D648 GHC Trac Issues: #9094 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #9395: Debug.Trace should not use %s for format string In-Reply-To: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> References: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> Message-ID: <060.fb22b8d7a5fa742bd093f0a18bcf8825@haskell.org> #9395: Debug.Trace should not use %s for format string -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a82364c9410d35fa9cb5031d553212267c3628c5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a82364c9410d35fa9cb5031d553212267c3628c5" Don't truncate traceEvents to 512 bytes (#8309) Summary: Don't call postLogMsg to post a user msg, because it truncates messages to 512 bytes. Rename traceCap_stderr and trace_stderr to vtraceCap_stderr and trace_stderr, to signal that they take a va_list (similar to vdebugBelch vs debugBelch). See #3874 for the original reason behind traceFormatUserMsg. See the commit msg in #9395 (d360d440) for a discussion about using null-terminated strings vs strings with an explicit length. Test Plan: Run `cabal install ghc-events` and inspect the result of `ghc-events show` on an eventlog file created with `ghc -eventlog Test.hs` and `./Test +RTS -l`, where Test.hs contains: ``` import Debug.Trace main = traceEvent (replicate 510 'a' ++ "bcd") $ return () ``` Depends on D655. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D656 GHC Trac Issues: #8309 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #9606: Improve outdated ghc-pkg cache warning In-Reply-To: <042.9c58fbc29cb9829bc37b485448322dc0@haskell.org> References: <042.9c58fbc29cb9829bc37b485448322dc0@haskell.org> Message-ID: <057.e5fed04f1f045c1fd42e07290b684924@haskell.org> #9606: Improve outdated ghc-pkg cache warning -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: ghc-pkg | 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:D658 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e7fab334b31dc516d2e8f2285630cbffe9825b76/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e7fab334b31dc516d2e8f2285630cbffe9825b76" Improve outdated ghc-pkg cache warning (#9606) Summary: No more frustration. Test Plan: I tested it. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D658 GHC Trac Issues: #9606 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.91cc4d125808f397fc3cca41f2df3f9f@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: 7.10.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 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"91d9530525803403c3c012901115d54ff4fc3b5e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="91d9530525803403c3c012901115d54ff4fc3b5e" Revert "Eta-expand argument to foldr in mapM_ for []" This change lacked justification (or a test!) for its improvements, and I merged it on a sweep of Phabricator without fixing this. Trac #10034. This reverts commit 7cf87fc6928f0252d9f61719e2344e6c69237079. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #8309: traceEvent truncates to 512 bytes In-Reply-To: <045.248642a5e64e6b0cbed6adafd24ed179@haskell.org> References: <045.248642a5e64e6b0cbed6adafd24ed179@haskell.org> Message-ID: <060.1336b67e04029f994118b2f1ce7295fb@haskell.org> #8309: traceEvent truncates to 512 bytes -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: eventlog Operating System: Unknown/Multiple | tracing Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #3874 | Test Case: | Blocking: | Differential Revisions: Phab:D656 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a82364c9410d35fa9cb5031d553212267c3628c5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a82364c9410d35fa9cb5031d553212267c3628c5" Don't truncate traceEvents to 512 bytes (#8309) Summary: Don't call postLogMsg to post a user msg, because it truncates messages to 512 bytes. Rename traceCap_stderr and trace_stderr to vtraceCap_stderr and trace_stderr, to signal that they take a va_list (similar to vdebugBelch vs debugBelch). See #3874 for the original reason behind traceFormatUserMsg. See the commit msg in #9395 (d360d440) for a discussion about using null-terminated strings vs strings with an explicit length. Test Plan: Run `cabal install ghc-events` and inspect the result of `ghc-events show` on an eventlog file created with `ghc -eventlog Test.hs` and `./Test +RTS -l`, where Test.hs contains: ``` import Debug.Trace main = traceEvent (replicate 510 'a' ++ "bcd") $ return () ``` Depends on D655. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D656 GHC Trac Issues: #8309 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS In-Reply-To: <042.a6da12ed13280b322366fdac32c894b2@haskell.org> References: <042.a6da12ed13280b322366fdac32c894b2@haskell.org> Message-ID: <057.b247f92a2bc47bd34e5d2f03a15352f7@haskell.org> #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D663 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"9caf71a8d9293cfebdbb5b28e2d6a455ad126882/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9caf71a8d9293cfebdbb5b28e2d6a455ad126882" Do not clobber CPPFLAGS nor LDFLAGS, fixes #10093 Summary: Append -I/-L flags to CPPFLAGS/LDFLAGS instead of clobbering. Test Plan: Install libiconv into /some/non-standard/path. Set CONF_GCC_LINKER_OPTS_STAGE{0,1,2} to -Wl,-rpath,/some/non- standard/path/lib. And then run ./configure with arguments --with-iconv- includes=/some/non-standard/path/include and --with-iconv-libraries=/some /non-standard/path/lib Reviewers: hvr, austin Reviewed By: austin Subscribers: thomie, PHO Differential Revision: https://phabricator.haskell.org/D663 GHC Trac Issues: #10093 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #9054: runghc- does not call ghc of the same version In-Reply-To: <048.09116779ce49b45664b7ce81fecc6578@haskell.org> References: <048.09116779ce49b45664b7ce81fecc6578@haskell.org> Message-ID: <063.fc1e7a60d28174ae819724bc88cfc129@haskell.org> #9054: runghc- does not call ghc of the same version -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 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: Phab:D664 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"6d17125dccda76b7aafe33181df822045ff5b9bf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6d17125dccda76b7aafe33181df822045ff5b9bf" runghc: be explicit about ghc version (#9054) Summary: runghc-7.x should always call ghc-7.x Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D664 GHC Trac Issues: #9054 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #9402: Vestigial external core code in genprimops In-Reply-To: <047.41ab882fa71501e8a7cbcb7207176a86@haskell.org> References: <047.41ab882fa71501e8a7cbcb7207176a86@haskell.org> Message-ID: <062.b051bc32aa490cf4a8912d5a472ad5bc@haskell.org> #9402: Vestigial external core code in genprimops -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch 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:D659 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"08102b3dcffb715938cf197b455f873e615d2bc2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="08102b3dcffb715938cf197b455f873e615d2bc2" Delete vestigial external core code (#9402) Test Plan: harbormaster Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D659 GHC Trac Issues: #9402 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 15:47:57 -0000 Subject: [GHC] #10091: Add configurable verbosity level to hpc executable In-Reply-To: <044.9bf53187879824adb106c81d41020873@haskell.org> References: <044.9bf53187879824adb106c81d41020873@haskell.org> Message-ID: <059.057dc0d097ba801b421eaa9b5188254c@haskell.org> #10091: Add configurable verbosity level to hpc executable -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | Status: new Priority: normal | Milestone: 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: Related Tickets: | Blocking: | Differential Revisions: Phab:D660 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"1b82619bc2ff36341d916c56b0cd67a378a9c222/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1b82619bc2ff36341d916c56b0cd67a378a9c222" Add configurable verbosity level to hpc Summary: All commands now have `--verbosity` flag, so one can configure cabal package with `--hpc-options="--verbosity=0"`. Right now it is used only in `hpc markup` to supress unnecessary output. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D660 GHC Trac Issues: #10091 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:01:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:01:57 -0000 Subject: [GHC] #9094: remove RAW_CPP In-Reply-To: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> References: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> Message-ID: <060.b48cb0cee2bf2a00835db335894dfb75@haskell.org> #9094: remove RAW_CPP -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.12.1 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: Related Tickets: #8683 | Blocking: | Differential Revisions: Phab:D648 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:02:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:02:59 -0000 Subject: [GHC] #8309: traceEvent truncates to 512 bytes In-Reply-To: <045.248642a5e64e6b0cbed6adafd24ed179@haskell.org> References: <045.248642a5e64e6b0cbed6adafd24ed179@haskell.org> Message-ID: <060.c7a38c9d616175229cef18469af2559d@haskell.org> #8309: traceEvent truncates to 512 bytes -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: eventlog Operating System: Unknown/Multiple | tracing Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #3874 | Test Case: | Blocking: | Differential Revisions: Phab:D656 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.12.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:03:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:03:38 -0000 Subject: [GHC] #9606: Improve outdated ghc-pkg cache warning In-Reply-To: <042.9c58fbc29cb9829bc37b485448322dc0@haskell.org> References: <042.9c58fbc29cb9829bc37b485448322dc0@haskell.org> Message-ID: <057.5826e3b5a0b3c47c7ed4d1a06cdc0a52@haskell.org> #9606: Improve outdated ghc-pkg cache warning -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: ghc-pkg | 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: | Differential Revisions: Phab:D658 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:04:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:04:13 -0000 Subject: [GHC] #9402: Vestigial external core code in genprimops In-Reply-To: <047.41ab882fa71501e8a7cbcb7207176a86@haskell.org> References: <047.41ab882fa71501e8a7cbcb7207176a86@haskell.org> Message-ID: <062.30f5989edf9f2dd052673c59a0bb1c56@haskell.org> #9402: Vestigial external core code in genprimops -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | 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: Phab:D659 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:05:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:05:05 -0000 Subject: [GHC] #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS In-Reply-To: <042.a6da12ed13280b322366fdac32c894b2@haskell.org> References: <042.a6da12ed13280b322366fdac32c894b2@haskell.org> Message-ID: <057.d45f208d8729bffecb1203c1de64b43b@haskell.org> #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D663 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Looks fine - merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:05:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:05:39 -0000 Subject: [GHC] #9054: runghc- does not call ghc of the same version In-Reply-To: <048.09116779ce49b45664b7ce81fecc6578@haskell.org> References: <048.09116779ce49b45664b7ce81fecc6578@haskell.org> Message-ID: <063.6d3dda38c6db5208638f477ca98e5de8@haskell.org> #9054: runghc- does not call ghc of the same version -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 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: Related Tickets: | Blocking: | Differential Revisions: Phab:D664 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:06:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:06:42 -0000 Subject: [GHC] #10099: cabal install broken with ghc 7.10.1-rc2 Message-ID: <047.602c37795a358463eb57e7ffa8e992ef@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 | Version: 7.10.1-rc2 system | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime crash Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2 consistently gives this error message (`primitive` is just an example): {{{ peter at montebre:~> cabal install primitive Resolving dependencies... Configuring primitive-0.5.4.0... cabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf }}} This is my package database: {{{ peter at montebre:~> ghc-pkg list /usr/lib64/ghc-7.10.0.20150123/package.conf.d Cabal-1.22.1.0 HTTP-4000.2.19 array-0.5.0.1 base-4.8.0.0 bin-package-db-0.0.0.0 binary-0.7.3.0 bytestring-0.10.6.0 containers-0.5.6.2 deepseq-1.4.0.0 directory-1.2.2.0 filepath-1.3.1.0 ghc-7.10.0.20150123 ghc-prim-0.3.1.0 haskeline-0.7.2.0 hoopl-3.10.0.2 hpc-0.6.0.2 integer-gmp-1.0.0.0 mtl-2.2.1 network-2.4.2.3 old-locale-1.0.0.7 old-time-1.1.0.3 parsec-3.1.8 pretty-1.1.2.0 process-1.2.2.0 random-1.0.1.1 rts-1.0 stm-2.4.2 syb-0.4.4 template-haskell-2.10.0.0 terminfo-0.4.0.1 text-1.2.0.4 th-desugar-1.5 th-lift-0.7 time-1.5.0.1 transformers-0.4.2.0 unix-2.7.1.0 xhtml-3000.2.1 zlib-0.5.4.2 }}} I updated only those packages (from their versions in Haskell Platform) that would not compile with 7.101-rc2. I am setting this to highest as this issue would be very annoying for everyone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:07:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:07:50 -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.a5727d83009d62d96ce90ef9c56f338e@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: new 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:6 goldfire]: > Did you report a cabal bug for comment:4? That looks independent from this bug or from singletons. Done. See #10099. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:10:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:10:57 -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.c6d7319d623887cd9c4b1140d65f837c@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: new 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:5 trommler]: > Replying to [comment:4 trommler]: > > I'm stuck at a Cabal error message: > > [...] > Alright, compiling the respective `Setup.hs` files for all dependencies and singletons, I can now reproduce the issue on Linux. I know what is going on. Fix is coming. comment:1 is a different issue but also related to the change in linking (#8935). I will prepare a separate patch for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 16:49:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 16:49:27 -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.1aaa7d310796b8665a21785b6aa38f84@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've run into the same problem this week but I assumed that I must have done something wrong with my installation and didn't have time to investigate further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 19:46:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 19:46:11 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.2780da1a5d9f672934a367fe5e9838a4@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: #8634 | -------------------------------------+------------------------------------- Comment (by jstolarek): > My guess is that PolyKinds is causing trouble in the not-promoted case. Spot-on. Without `PolyKinds` this works perfectly fine. > But, the "redundant constraint" warning is almost certainly wrong. Yes. Now that the non-promoted version compiles it produces the same warning. I'll fill a bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 19:51:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 19:51:15 -0000 Subject: [GHC] #10100: Bogus "redundant constraint" warning with functional dependencies Message-ID: <048.9dcc7a939a45b31fb0e7cae24622ba1c@haskell.org> #10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | 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: | -------------------------------------+------------------------------------- Compiling this code with GHC HEAD: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} module T10100 where data Zero data Succ a class Add a b ab | a b -> ab, a ab -> b instance Add Zero b b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} Gives a bogus warning about redundant constraint: {{{ Redundant constraint: Add a b ab In the instance declaration for ?Add (Succ a) b (Succ ab)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 19:55:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 19:55:09 -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.c716b1727ef715fe77a11a01ee29d613@haskell.org> #10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: simonpj Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => simonpj * milestone: => 7.10.1 Comment: I believe that: * this should be fixed in GHC 7.10. I'm setting milestone to 7.10.1 but if there's no time to fix it for 7.10.1 release then please punt it to 7.10.2 * Simon implemented this check, so I'm setting owner to simonpj. Simon, I hope this is correct but if not then please unassign yourself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 21:58:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 21:58:43 -0000 Subject: [GHC] #10101: ghci :e throws exception after type error Message-ID: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> #10101: ghci :e throws exception after type error -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After a type-error on the command line, :e starts throwing an exception. To reproduce: {{{ ~/src/ghc/inplace/bin/ghc-stage2 --interactive test.hs GHCi, version 7.11.20150128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> 1 + () :2:3: No instance for (Num ()) arising from a use of ?+? In the expression: 1 + () In an equation for ?it?: it = 1 + () *Main> :e *** Exception: : canonicalizePath: does not exist (No such file or directory) *Main> }}} The contents of `test.hs` is not important as long as there is a file to edit. Editing works fine before the type-error on the command line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 18 22:37:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Feb 2015 22:37:09 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.ec0624ac64e759ed3895b27e39696156@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: #8634 | -------------------------------------+------------------------------------- Comment (by jstolarek): > My guess is that PolyKinds is causing trouble in the not-promoted case. I have to ask: how did you figure that out? I don;t see anything in the error message (nor in the code) that would suggest PolyKinds are causing the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 01:18:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 01:18:04 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.46f2433d97baa05c9977c6346a5f3902@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 Austin Seipp ): In [changeset:"e9d72cefeda243d5962d0615fe7ad22ff615d134/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e9d72cefeda243d5962d0615fe7ad22ff615d134" Fix #10045 Summary: SPJ's solution is to only bring the `TcId` (which includes the type) of a binder into scope when it had a non-partial type signature. Take care of this by only storing the `TcId` in `TcSigInfo` of non-partial type signatures, hence the change to `sig_poly_id :: Maybe TcId`. Only in case of a `Just` will we bring the `TcId` in scope. We still need to know the name of the binder, even when it has a partial type signature, so add a `sig_name :: Name` field. The field `sig_partial :: Bool` is no longer necessary, so reimplement `isPartialSig` in terms of `sig_poly_id`. Note that the new test case fails, but not because of a panic, but because the `Num a` constraint is missing. Adding an extra-constraints wildcard to `copy`'s signature would fix it. Test Plan: validate Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D646 GHC Trac Issues: #10045 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 08:26:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 08:26:54 -0000 Subject: [GHC] #9615: GHC panic: Loading temp shared object failed In-Reply-To: <042.4e53618d00dd07f1d8d85e351181a7b3@haskell.org> References: <042.4e53618d00dd07f1d8d85e351181a7b3@haskell.org> Message-ID: <057.bdd6e73361777b5a11a9853ea416a060@haskell.org> #9615: GHC panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 jpbernardy): I think that this bug is connected to Template Haskell. (If I remove the use of T-H. the problem disappears) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 10:40:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 10:40:58 -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.491c6c5ee07d77c261dcb11d91c39c13@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 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D669 Comment: The 2010 report, section 11.4, mentions: "The result of `show` is a syntactically correct Haskell expression ... Parenthesis are only added where needed ..." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 17:37:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 17:37:38 -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.b923eb5c33e0053bccb40ed23465c304@haskell.org> #10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: simonpj Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Comment (by simonpj): Humph. In one sense the constraint IS redundant: you simply don't need the evidence (dictionary) for `Add a b ab` to create evidence for `Add (Succ a) b (Succ ab)`. But you want nevertheless to allow this (or not warn about it), because you want to prove things like `Add (Succ Zero) beta (Succ Zero)`, by unifying `beta := Zero`. That won't happen unless you generate the constraint `Add Zero beta Zero`. Hmm, well I suppose we should suppress the warnings where there are functional dependencies. I'll work on it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 18:00:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 18:00:18 -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.316e18a67e22aee7c847176a440b7534@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 George): I don't have this problem and have had none with cabal install cabal install primitive Resolving dependencies... All the requested packages are already installed: primitive-0.5.4.0 Use --reinstall if you want to reinstall anyway. 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"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno- unicode -Wno-trigraphs ") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.10.0.20150123") ,("Project Git commit id","174082ffeb69b2f9df19e7af7b63a331dd074145") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("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") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.10.0.20150123") ,("Global Package DB","/usr/local/lib/ghc-7.10.0.20150123/package.conf.d") ] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 20:02:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 20:02:57 -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.ca0ef32d2c53ee202e00aadcc17ce9b8@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 trommler): Replying to [comment:2 George]: > Did you build 7.10-rc2 or install it from a binary? I built ghc from the source tarball and then again with the resulting ghc. So my ghc was bootstrapped with ghc 7.10.1-rc2. > > I don't have this problem and have had none with cabal install. I installed from a binary. > > cabal install primitive > Resolving dependencies... > All the requested packages are already installed: > primitive-0.5.4.0 > Use --reinstall if you want to reinstall anyway. > > $ ghc-pkg list > /usr/local/lib/ghc-7.10.0.20150123/package.conf.d: > [...] > /Users/gcolpitts/.ghc/x86_64-darwin-7.10.0.20150123/package.conf.d: > [...] > primitive-0.5.4.0 You have primitive installed already, I don't. Here is my ghc info: {{{ $ 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","/usr/bin/llc") ,("LLVM opt command","/usr/bin/opt") ,("Project version","7.10.0.20150123") ,("Project Git commit id","174082ffeb69b2f9df19e7af7b63a331dd074145") ,("Booter version","7.10.0.20150123") ,("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") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib64/ghc-7.10.0.20150123") ,("Global Package DB","/usr/lib64/ghc-7.10.0.20150123/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 20:08:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 20:08:48 -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.c7e25f8afa13cb12b3625fc5527ee7ec@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 also built 7.10.1-RC2 from source, although I did not bootstrap for the second time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 21:27:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 21:27:06 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.db6eaf8f2a79b4cd4fd83c6bddfd1cd4@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => D671 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 22:27:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 22:27:48 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.ad80c2b526a6f93391a9c4482fd0cd0b@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: #8634 | -------------------------------------+------------------------------------- Comment (by simonpj): OK, so aside from the "redundant constraint" problem (now reported as #10100), what's left in this ticket? * The error message looks absolutely right to me. {{{ Data/TypeLevel/Num/Ops.hs:90:10: Illegal instance declaration for ?Succ' (x, x) (x, x) D0 D0 True? The liberal coverage condition fails in class ?Succ'? for functional dependency: ?yh yl yz -> xh xl? Reason: lhs types ?D0?, ?D0?, ?True? do not jointly determine rhs types ?(x, x)?, ?(x, x)? In the instance declaration for ?Succ' (x, x) (x, x) D0 D0 True? }}} * Yes, the user manual about "lifting the Paterson conditions" is wrong: see #8634, comment:14. * If, for some reason, this code is really really what you want, then you need `DysFunctionalDependencies`; for that see #8634. So can we close this ticket? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 22:40:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 22:40:34 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.355f1e8f31cc79b5003f5e5768a049c6@haskell.org> #4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dmcclean): Could anyone provide an update on the current state of efforts to improve the constraint solver? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 23:06:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 23:06:57 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.8b0c6babcaac470872f6fa578ec7d30a@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: #8634 | -------------------------------------+------------------------------------- Comment (by jstolarek): Looking again at my comment:7 I believe it is a bug that enabling `PolyKinds` breaks a correct program. That's of course not related to the original bug and deserves its separate bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 23:23:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 23:23:32 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.cfbfc74915318e4081658f55d58dd20c@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: #8634 | -------------------------------------+------------------------------------- Comment (by simonpj): OK go ahead an open another ticket, and close this one. But as you'll see with `-fprint-explicit-kinds`, the coverage condition really is violated. You may say it's a bug but I don't see a reasonable way to fix it. (A better error message would be good, I grant you.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 23:31:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 23:31:49 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.c248207d3ab362be06956caf7888063e@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new 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 simonpj): Can you try with the 7.10 release candidate? Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 19 23:34:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Feb 2015 23:34: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.f479985bbd64cd8f2637488c2510e113@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > I used hprotoc to generate some code for Google protocol buffers. > > The QueryValue.proto file is attached. > > You can install hprotoc tool using cabal. > then use > ''hprotoc QueryValue.proto'' > to generate code. Then create a minimal cabal file. > ''cabal init -m --is-library -n'' > Then if you build it with '''optimization enabled''', the build will fail > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.3 for x86_64-apple-darwin): > Simplifier ticks exhausted > When trying UnfoldingDone $j_sEMq{v} [lid] > To increase the limit, use -fsimpl-tick-factor=N (default 100) > If you need to do this, let GHC HQ know, and what factor you needed > To see detailed counts use -ddump-simpl-stats > Total ticks: 59242 New description: I used hprotoc to generate some code for Google protocol buffers. The QueryValue.proto file is attached. You can install `hprotoc` tool using cabal. then use {{{ hprotoc QueryValue.proto }}} to generate code. Then create a minimal cabal file. {{{ cabal init -m --is-library -n }}} Then if you build it with '''optimization enabled''', the build will fail {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_sEMq{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 59242 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 02:33:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 02:33:33 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.bb452b6e207481ad816f8aa15eed744a@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: -------------------------------------+------------------------------------- Comment (by pacak): Haskell code itself that generates slowdown, I've managed to get rid of most of dependencies that not in Haskell Platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 07:55:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 07:55:01 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.69bd998ce582bfc97fa7864f4a03dcbc@haskell.org> #4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): Iavor can probably say more than me, but I believe he is currently working on a type-nats constraint solver as a typechecker plugin that communicates with an SMT solver: https://github.com/yav/type-nat-solver More generally, the aim of the typechecker plugins work is to make this sort of thing easier to experiment with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 07:59:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 07:59:25 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.113f2e04d5fca2ee15e6160b32e0d0ab@haskell.org> #4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | 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: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adam.gundry@? (removed) * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 08:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 08:47:57 -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.e8a2ddf5f9539a75ac270bf5f5b0c639@haskell.org> #10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: simonpj Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"10fab31211961c9200d230556ec7742e07a6c831/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="10fab31211961c9200d230556ec7742e07a6c831" Don't report instance constraints with fundeps as redundant More subtlety due to functional dependencies. Note [Redundant constraints in instance decls] in TcErrors. Fixes Trac #10100. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 08:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 08:47:57 -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.beba134033ffafd028ba95b5ebca9e1c@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new 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: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9c78d09e344e97d2d5c37b9bb46e311a3cf031e2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9c78d09e344e97d2d5c37b9bb46e311a3cf031e2" Add a bizarre corner-case to cgExpr (Trac #9964) David Feuer managed to tickle a corner case in the code generator. See Note [Scrutinising VoidRep] in StgCmmExpr. I rejigged the comments in that area of the code generator Note [Dodgy unsafeCoerce 1] Note [Dodgy unsafeCoerce 2] but I can't say I fully understand them, alas. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 08:52:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 08:52:03 -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.ed9c0f7ce29d523a820a000daa4678ea@haskell.org> #10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: simonpj Type: bug | Status: merge Priority: normal | 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: | typecheck/should_compile/T10100 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T10100 Comment: I've fixed this and added the example as a test. Merge to 7.10 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 08:53:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 08:53:28 -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.39eff35da2063d2d76cc0680eee4a2f3@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: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => codeGen/should_compile/T9964 Comment: Well that is indeed a bizarre example David. Did it arise from real code in some way? Anyway I believe I've fixed it. Merge to 7.10 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 11:04:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 11:04:17 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.6bfcd0ee9be1434d0cc7acd2ef6229cd@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: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 12:31:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 12:31:38 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.5b22270cd4ed917b3ef124a52c910f2d@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: -------------------------------------+------------------------------------- Comment (by simonpj): The dependencies are still substantial, on `lens` in particular. pacak tells me that he is working on cutting it down further. (Thank you.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 12:47:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 12:47:22 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.b63ff0dcfbeb074ec323cbd56e7ceeb0@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: -------------------------------------+------------------------------------- Comment (by pacak): Simon, did you checked most recent upload? From non-base packages that's only enummapset-th and lifted-base -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 13:09:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 13:09:38 -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.02ea28ed71bae48f3079a3df90e3461c@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 dfeuer): Replying to [comment:6 simonpj]: > Well that is indeed a bizarre example David. Did it arise from real code in some way? > > Anyway I believe I've fixed it. > > Merge to 7.10 > > Simon A while back, I asked whether `seq#` was really necessary to implement `evaluate`. I was trying to figure out if sufficient `NOINLINE` use would be able to avoid it. I was a bit surprised to crash the compiler! The example given is only slightly stripped down from my initial experiment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 18:39:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 18:39:46 -0000 Subject: [GHC] #10102: GHC inlines past lambda in do-notation Message-ID: <046.54878955c94cdec15cc1b787f40cba48@haskell.org> #10102: GHC inlines past lambda in do-notation -------------------------------------+------------------------------------- Reporter: nomeata | 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: | -------------------------------------+------------------------------------- Hi, a friend of mine discovered this weird behaviour: The program, when run on the attached file, takes quite some time. {{{ import System.IO import Control.Monad import qualified Data.Map as M main :: IO () main = do n <- read `fmap` getLine q <- read `fmap` getLine mts <- replicateM n $ do [a,b] <- words `fmap` getLine return (a,b) let mtdb2 = M.fromList mts --M.null mtdb2 `seq` return () replicateM_ q $ do a <- getLine print $ M.lookup a mtdb2 return () }}} But if I uncomment the use of `mtdb2` outside the replicate, it runs fast. My conclusion is that GHC inlines `mtdb2` into the body of the loop, repeating the construction of the map over and over. If `forM [1..q] $ \_ -> do` is used instead, this does not happen ? probably because GHC does _not_ inline past that lambda. (I didn?t attempt to understand the core yet) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 18:57:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 18:57:42 -0000 Subject: [GHC] #10103: Outdated comment (or bug?) in TyCon.hs Message-ID: <045.91b7f7fba8a388fdcef9bd508a30b4ac@haskell.org> #10103: Outdated comment (or bug?) in TyCon.hs -------------------------------------+------------------------------------- Reporter: thomie | 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: | -------------------------------------+------------------------------------- The docstring for `coreExpandTyCon_maybe` says it should do something different than `tcExpandTyCon_maybe`, but it doesn't: {{{#!haskell -- ^ Used to create the view the /typechecker/ has on 'TyCon's. -- We expand (closed) synonyms only, cf. 'coreExpandTyCon_maybe' tcExpandTyCon_maybe = ... -- ^ Used to create the view /Core/ has on 'TyCon's. We expand -- not only closed synonyms like 'tcExpandTyCon_maybe', -- but also non-recursive @newtype at s coreExpandTyCon_maybe tycon tys = tcExpandTyCon_maybe tycon tys }}} If the code is correct, and the comment is just outdated, than Note [Newtype eta] and the docstring for `Type.coreView` should be updated as well. The last big change to `coreExpandTyCon_maybe` was made in commit fdf8656855d26105ff36bdd24d41827b05037b91. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 19:08:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 19:08:14 -0000 Subject: [GHC] #10103: Outdated comment (or bug?) in `types/TyCon.hs` (was: Outdated comment (or bug?) in TyCon.hs) In-Reply-To: <045.91b7f7fba8a388fdcef9bd508a30b4ac@haskell.org> References: <045.91b7f7fba8a388fdcef9bd508a30b4ac@haskell.org> Message-ID: <060.f1f3d0a79487abe9508a089c26ce0501@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 | 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 thomie: Old description: > The docstring for `coreExpandTyCon_maybe` says it should do something > different than `tcExpandTyCon_maybe`, but it doesn't: > > {{{#!haskell > -- ^ Used to create the view the /typechecker/ has on 'TyCon's. > -- We expand (closed) synonyms only, cf. 'coreExpandTyCon_maybe' > tcExpandTyCon_maybe = ... > > -- ^ Used to create the view /Core/ has on 'TyCon's. We expand > -- not only closed synonyms like 'tcExpandTyCon_maybe', > -- but also non-recursive @newtype at s > coreExpandTyCon_maybe tycon tys = tcExpandTyCon_maybe tycon tys > }}} > > If the code is correct, and the comment is just outdated, than Note > [Newtype eta] and the docstring for `Type.coreView` should be updated as > well. > > The last big change to `coreExpandTyCon_maybe` was made in commit > fdf8656855d26105ff36bdd24d41827b05037b91. New description: The docstring for `coreExpandTyCon_maybe` says it should do something different than `tcExpandTyCon_maybe`, but it doesn't: {{{#!haskell -- ^ Used to create the view the /typechecker/ has on 'TyCon's. -- We expand (closed) synonyms only, cf. 'coreExpandTyCon_maybe' tcExpandTyCon_maybe = ... -- ^ Used to create the view /Core/ has on 'TyCon's. We expand -- not only closed synonyms like 'tcExpandTyCon_maybe', -- but also non-recursive @newtype at s coreExpandTyCon_maybe tycon tys = tcExpandTyCon_maybe tycon tys }}} If the code is correct, and the comment is just outdated, than Note [Newtype eta] and the docstrings for `Type.coreView` and `Type.tcView` should be updated as well. The last big change to `coreExpandTyCon_maybe` was made in commit fdf8656855d26105ff36bdd24d41827b05037b91. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 20 23:26:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Feb 2015 23:26:54 -0000 Subject: [GHC] #10104: Show '#' on unboxed literals Message-ID: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> #10104: Show '#' on unboxed literals -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #8274 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, unboxed literals are shown in the same way as boxed literals (without #): {{{ Prelude> :set -XMagicHash Prelude> :m GHC.Prim Prelude GHC.Prim> data T = MkT Int# deriving Show Prelude GHC.Prim> MkT 3# MkT 3 }}} It would be nice if this would show `MkT 3#` instead. I have a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 00:44:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 00:44:29 -0000 Subject: [GHC] #10104: Show '#' on unboxed literals In-Reply-To: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> References: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> Message-ID: <060.1b544620601ddad7a9d86f9a62ae9bce@haskell.org> #10104: Show '#' on unboxed literals -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: patch 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: #8274 | Blocking: | Differential Revisions: Phab:D672 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D672 Comment: Also handle `Char#`, `Word#`, `Float#` and `Double#`. And don't show superfluous parenthesis around negative unboxed literals. For reference: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html#magic-hash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 00:45:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 00:45:25 -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.25148facf8d54e00c308283fec139311@haskell.org> #8274: Core pretty-printer doesn't print # on unboxed literals -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10104 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 00:48:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 00:48:20 -0000 Subject: [GHC] #10104: Show '#' on unboxed literals In-Reply-To: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> References: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> Message-ID: <060.8c9cf5c43ebb8c05312d291ae25ff367@haskell.org> #10104: Show '#' on unboxed literals -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: patch 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: #8274 | deriving/should_run/T10104 | Blocking: | Differential Revisions: Phab:D672 -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => deriving/should_run/T10104 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 01:24:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 01:24:37 -0000 Subject: [GHC] #8280: Deriving Show for Word# In-Reply-To: <047.33660271255b789211e22afbdb2df884@haskell.org> References: <047.33660271255b789211e22afbdb2df884@haskell.org> Message-ID: <062.2ff40b294ccf0b44b1380ded0ec06cca@haskell.org> #8280: Deriving Show for Word# -------------------------------------+------------------------------------- Reporter: monoidal | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | deriving/should_run/T10104 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: deriving/should_run/T8280 => deriving/should_run/T10104 Comment: With Phab:D672 (#10104), `deriving/should_run/T10104` supersedes `deriving/should_run/T8280`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 02:23:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 02:23:55 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.5540e9a59dc21b21abfd61b3f764d560@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+----------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by George): I cannot reproduce this i 7.10.rc2 with the original test case: {{{ 12345678901234567890 ^ 12345 }}} Can others reproduce it on 7.10.rc2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 05:35:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 05:35:20 -0000 Subject: [GHC] #10105: ghc panic Simplifier ticks exhausted when trying UnfoldingDone x_alB Message-ID: <050.e25d389a8920cf1d1cafbe416375e037@haskell.org> #10105: ghc panic Simplifier ticks exhausted when trying UnfoldingDone x_alB -------------------------------------+------------------------------------- Reporter: | Owner: dramforever | 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: | -------------------------------------+------------------------------------- The following code causes a panic. It's the Y combinator. {{{#!hs module Y where newtype F a = F { unF :: F a -> a } y :: (a -> a) -> a y = \f -> (\x -> x (F x)) (\x -> f (unF x x)) }}} {{{ bash$ ~/src/ghc-7.10.0.20150123/installed/bin/ghc -c Y.hs ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150123 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone x_alB To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 4722 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} However it works fine in GHCi {{{ bash$ ~/src/ghc-7.10.0.20150123/installed/bin/ghci Y.hs GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Y ( Y.hs, interpreted ) Ok, modules loaded: Y. *Y> take 10 (y (1:)) [1,1,1,1,1,1,1,1,1,1] }}} I have tried this code with 7.6.3, 7.8.3 and 7.10.1-rc2. Same result. At least in 7.10.1-rc2 it doesn't work even with -fsimpl-tick- factor=100000 (that's 10^5^) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 05:39:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 05:39:51 -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.1162ef9ca056d1bff5e54d690473d350@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): In case you didn't get it, I installed 7.10.1-rc2 in prefix ~/src/ghc-7.10.0.20150123/installed/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 11:30:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 11:30:27 -0000 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@haskell.org> References: <047.1e9bce153303809272446b6c0aede02d@haskell.org> Message-ID: <062.66823f0565d281b4eed49aafcef8ec6d@haskell.org> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | nofib/spectral/calendar | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): See #10102 for another example (but nothing excitingly new there). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 11:31:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 11:31:00 -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.d93873f0147da9ec26dcd6292c5494f5@haskell.org> #10102: GHC inlines past lambda in do-notation -------------------------------------+------------------------------------- Reporter: nomeata | 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 nomeata): BTW, it does not occur with `-fno-state-hack`. So it?s likely a duplicate of the known problem that the state hack can go wrong, e.g. #1168, #9349. Might be fixed by #9388. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 11:32:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 11:32:44 -0000 Subject: [GHC] #9388: Narrow the scope of the notorious "state hack" In-Reply-To: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> References: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> Message-ID: <061.7c1d62c0f08cf9d5096d2cd78d3ceeb1@haskell.org> #9388: Narrow the scope of the notorious "state hack" -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 11:38:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 11:38:06 -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.c01c007cb8e9697e9001a7bf7410bd6b@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: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 13:56:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 13:56:32 -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.2835721b9f8088469bc9f8a63b830c3f@haskell.org> #7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): So what's the status of this ticket then? Should it just be closed? I can't really follow what should happen here :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 13:58:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 13:58:59 -0000 Subject: [GHC] #4372: Extending quasiquotation support In-Reply-To: <046.070081740d53fd2b18d950319658559f@haskell.org> References: <046.070081740d53fd2b18d950319658559f@haskell.org> Message-ID: <061.8f77de7e3606fef9faaab04899c8fc48@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 songzh): Replying to [comment:16 thoughtpolice]: > Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone. Why this is being moved to 7.12? I was excited that it could be resolving in 7.10. I am only a newbie of Haskell, but I want to address something about this problem. I want to write type provider for Haskell that generates data type definition from JSON or OData sources. For example: {{{ {"name" : "Ciambellone Cake", "ingredients": [{ "name": "Flour", "quantity": 250, "measure": "gr" }]} }}} should generate {{{ data Recipe = Recipe { recipeName :: String, recipeIngredients: [Ingredient]} data Ingredient = Ingredient { ingredientName :: String, ingredientQuantity :: Int, ingredientMeasure :: String} }}} However, you need to give a type name when you do it (Here, it is Recipe). In F#, just write: {{{ type Recipe = JsonProvider<"JSONSample.json"> }}} However, it seems that we cannot do this in TH (I tried but cannot do it, if we can do tell me please!): {{{ data Recipe = $(templateHaskellpart) }}} which means we have to have a parameterized quoter {{{ quotejson :: String -> QuasiQuoter quotejson name = QuasiQuoter { quoteDec = \jsonStr -> gen name (getJSON jsonStr) } getJSON :: String -> JValue gen :: String -> JValue -> Q [Dec] }}} Being unable to do this means that we have to define a json quoter for each we need in a separated module, which is painful. Well, we can use quoteExp so solve this, however, the quotation marks and other special characters in JSON or other data sources can be very annoying sometimes. Another problem is that I suppose that the 4 quoters t, p, e, d are implemented in the layer of syntax, i.e. they do not have QuasiQuoter type, so if I want to defined a quoter called e or d, it seems to be impossible. I personally suppose that it might be better if the 4 quoters are provided in library layer instead of syntax level, just like other regular quoters. By which I mean we can define the lexer as following: {{{ '[' quoterExp '|' strings '|]' }}} and hand quoterExp afterwards. I do not understand why it is implemented in current way. Apologize if I said something stupid. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 17:17:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 17:17:12 -0000 Subject: [GHC] #10106: GHC doesn't warn on typos in language pragmas Message-ID: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> #10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In particular, I was struggling with the QuasiQuotes language extension. I had - {{{#!hs {-# LANGAUGE QuasiQuotes #-} site = [shamelet|Hello World!|] }}} Notice the transposed A and U in `LANGUAGE` The error that ghc was emitting was - `Main.hs:23:47: parse error on input ?]?` It took me a long time and a lot of head-banging to figure out that it was a typo in the language pragma, especially because the language pragma was surrounded by other language pragmas and it was at the top of the file. I would think that this should at least emit a warning when there is a typo in a pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 17:17:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 17:17:35 -0000 Subject: [GHC] #10106: GHC doesn't warn on typos in language pragmas In-Reply-To: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> References: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> Message-ID: <060.cf22c8e36bb4b943b43380e41aa6d227@haskell.org> #10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 sdemos): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 21:13:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 21:13:41 -0000 Subject: [GHC] #10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8" In-Reply-To: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> References: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> Message-ID: <065.58f9ee98ea16cc4a6606ca9ca413531b@haskell.org> #10090: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8" -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | 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 int-e): * related: #9370 => #4012 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 21:16:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 21:16:06 -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.f8d65dfde59aed21c0bf8d86c94f7371@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 may have found a way to reliably reproduce this bug using real code: attempt to bootstrap ''cabal-install'' 1.20.0.0 32-bit Red Hat Enterprise Linux 6.5, released on 11/11/2014 (Amazon EC2 image ID `ami-da3d82b2`). The official 32-bit GHC 7.8.4 bindist (file name `ghc-7.8.4-i386-unknown- linux-centos65.tar.xz`) panics: {{{ ... Configuring Cabal-1.20.0.0... Building Cabal-1.20.0.0... Preprocessing library Cabal-1.20.0.0... [ 1 of 78] Compiling Paths_Cabal ( dist/build/autogen/Paths_Cabal.hs, dist/build/Paths_Cabal.o ) [ 2 of 78] Compiling Distribution.TestSuite ( Distribution/TestSuite.hs, dist/build/Distribution/TestSuite.o ) [ 3 of 78] Compiling Distribution.Simple.PreProcess.Unlit ( Distribution/Simple/PreProcess/Unlit.hs, dist/build/Distribution/Simple/PreProcess/Unlit.o ) [ 4 of 78] Compiling Distribution.GetOpt ( Distribution/GetOpt.hs, dist/build/Distribution/GetOpt.o ) [ 5 of 78] Compiling Distribution.PackageDescription.Utils ( Distribution/PackageDescription/Utils.hs, dist/build/Distribution/PackageDescription/Utils.o ) [ 6 of 78] Compiling Distribution.Simple.CCompiler ( Distribution/Simple/CCompiler.hs, dist/build/Distribution/Simple/CCompiler.o ) [ 7 of 78] Compiling Distribution.Compat.ReadP ( Distribution/Compat/ReadP.hs, dist/build/Distribution/Compat/ReadP.o ) [ 8 of 78] Compiling Distribution.Text ( Distribution/Text.hs, dist/build/Distribution/Text.o ) [ 9 of 78] Compiling Distribution.Version ( Distribution/Version.hs, dist/build/Distribution/Version.o ) [10 of 78] Compiling Distribution.Compiler ( Distribution/Compiler.hs, dist/build/Distribution/Compiler.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for i386-unknown-linux): StgCmmEnv: variable not found $dOrd_aJIr{v} [lid] local binds for: Cabal-1.20.0.0:Distribution.Compiler.knownCompilerFlavors{v rJxS} [gid] Cabal-1.20.0.0:Distribution.Compiler.parseCompilerFlavorCompat{v rJxU} [gid] Cabal-1.20.0.0:Distribution.Compiler.buildCompilerFlavor{v rJxV} [gid] Cabal-1.20.0.0:Distribution.Compiler.buildCompilerId{v rJxX} [gid] Cabal-1.20.0.0:Distribution.Compiler.defaultCompilerFlavor{v rJxY} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerId{v rJyS} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor{v rJyV} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor{v rJyX} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor{v rJyZ} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fEqCompilerFlavor{v rJz1} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerFlavor{v rJz3} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fTypeableCompilerFlavor{v rJz5} [gid[DFunId(nt)]] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor{v rJz8} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fEqCompilerId{v rJza} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerId{v rJzc} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId{v rJze} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerId{v rJzg} [gid[DFunId]] Cabal-1.20.0.0:Distribution.Compiler.$tCompilerFlavor{v rJzi} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cGHC{v rJA5} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cNHC{v rJA6} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cYHC{v rJA7} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cHugs{v rJA8} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cHBC{v rJA9} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cHelium{v rJAa} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cJHC{v rJAb} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cLHC{v rJAc} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cUHC{v rJAd} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cHaskellSuite{v rJAe} [gid] Cabal-1.20.0.0:Distribution.Compiler.$cOtherCompiler{v rJAf} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgmapMo{v rJNI} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$cgmapMo{v rKP4} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgmapMp{v rKP5} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$cgmapMp{v rKP6} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgmapM{v rKP7} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgfoldl{v rKP8} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor1{v rKP9} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor2{v rKPa} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgmapQi{v rKPb} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$cgmapQi{v rKPc} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgmapQ{v rKPd} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgmapQr{v rKPe} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgmapQl{v rKPf} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgmapT{v rKPg} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cdataCast2{v rKPh} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cdataCast1{v rKPi} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cdataTypeOf{v rKPj} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor3{v rKPk} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor4{v rKPl} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor5{v rKPm} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor6{v rKPn} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor7{v rKPo} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor8{v rKPp} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor9{v rKPq} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor10{v rKPr} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor11{v rKPs} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor12{v rKPt} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor13{v rKPu} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor14{v rKPv} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor15{v rKPw} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$ctoConstr{v rKPx} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$cgunfold{v rKPy} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$cgunfold{v rKPz} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_$ctypeRep#{v rKPA} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor16{v rKPB} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor17{v rKPC} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_ww5{v rKPD} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_ww4{v rKPE} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fDataCompilerFlavor_ww3{v rKPF} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fEqCompilerFlavor_$c/={v rKPG} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fEqCompilerFlavor_$c=={v rKPH} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fEqCompilerId_$c/={v rKPI} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fEqCompilerId_$c=={v rKPJ} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$c=={v rKPK} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerFlavor_$cmin{v rKPL} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerFlavor_$ccompare{v rKPM} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerFlavor_$cmax{v rKPN} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerFlavor_$c<={v rKPO} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerFlavor_$c>{v rKPP} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerFlavor_$c>={v rKPQ} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerFlavor_$c<{v rKPR} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerId_$cmin{v rKPS} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerId_$cmax{v rKPT} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerId_$c<={v rKPU} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$c<={v rKPV} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerId_$c>{v rKPW} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$c>{v rKPX} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerId_$c>={v rKPY} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$c>={v rKPZ} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerId1{v rKQ0} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerId_$c<{v rKQ2} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$c<{v rKQ3} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fOrdCompilerId_$ccompare{v rKQ4} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$ccompare{v rKQ5} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor_$creadListPrec{v rKQ6} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor1{v rKQ7} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor2{v rKQ8} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor3{v rKQ9} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor4{v rKQa} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor5{v rKQb} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor6{v rKQc} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor7{v rKQd} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor8{v rKQe} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor9{v rKQf} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor10{v rKQg} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor11{v rKQh} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor12{v rKQi} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor13{v rKQj} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor14{v rKQk} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor15{v rKQl} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor16{v rKQm} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor17{v rKQn} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor18{v rKQo} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor19{v rKQp} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor20{v rKQq} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor21{v rKQr} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor22{v rKQs} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor23{v rKQt} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor24{v rKQu} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor25{v rKQv} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor26{v rKQw} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor27{v rKQx} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor28{v rKQy} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor29{v rKQz} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor30{v rKQA} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor31{v rKQB} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor32{v rKQC} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor33{v rKQD} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor34{v rKQE} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor35{v rKQF} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor36{v rKQG} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor37{v rKQH} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor38{v rKQI} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor39{v rKQJ} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor40{v rKQK} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor41{v rKQL} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor_$creadPrec{v rKQM} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor_$creadList{v rKQN} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor42{v rKQO} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerFlavor_$creadsPrec{v rKQP} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId_$creadListPrec{v rKQQ} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId1{v rKQR} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId2{v rKQS} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId3{v rKQT} [gid] Cabal-1.20.0.0:Distribution.Compiler.$wa{v rKQU} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId4{v rKQV} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId5{v rKQW} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId_$creadPrec{v rKQX} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId_$creadList{v rKQY} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId6{v rKQZ} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fReadCompilerId_$creadsPrec{v rKR0} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor_$cshowList{v rKR1} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor1{v rKR2} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor2{v rKR3} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor_$cshowsPrec{v rKR4} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor3{v rKR5} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor4{v rKR6} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor5{v rKR7} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor6{v rKR8} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor7{v rKR9} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor8{v rKRa} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor9{v rKRb} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor10{v rKRc} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor11{v rKRd} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor12{v rKRe} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor13{v rKRf} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerFlavor_$cshow{v rKRg} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerId_$cshowList{v rKRh} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerId1{v rKRi} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$cshowsPrec{v rKRj} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerId2{v rKRk} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerId_$cshow{v rKRl} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$cshow{v rKRm} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fShowCompilerId_$cshowsPrec{v rKRn} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor_$cparse{v rKRo} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor1{v rKRp} [gid] Cabal-1.20.0.0:Distribution.Compiler.$wa1{v rKRq} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor2{v rKRr} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor3{v rKRs} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor4{v rKRt} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor5{v rKRu} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor6{v rKRv} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor7{v rKRw} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor8{v rKRx} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor9{v rKRy} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor10{v rKRz} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor_go{v rKRA} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor_$cdisp{v rKRB} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor11{v rKRC} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor12{v rKRD} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor_s{v rKRE} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor13{v rKRF} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor14{v rKRG} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor15{v rKRH} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor16{v rKRI} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor17{v rKRJ} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor18{v rKRK} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor19{v rKRL} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerFlavor20{v rKRM} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerId_$cparse{v rKRN} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerId1{v rKRO} [gid] Cabal-1.20.0.0:Distribution.Compiler.$wa2{v rKRP} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerId2{v rKRQ} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerId3{v rKRR} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerId4{v rKRS} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerId_$cdisp{v rKRT} [gid] Cabal-1.20.0.0:Distribution.Compiler.$w$cdisp{v rKRU} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerId5{v rKRV} [gid] Cabal-1.20.0.0:Distribution.Compiler.$fTextCompilerId6{v rKRW} [gid] Cabal-1.20.0.0:Distribution.Compiler.buildCompilerFlavor1{v rKRX} [gid] Cabal-1.20.0.0:Distribution.Compiler.parseCompilerFlavorCompat1{v rKRY} [gid] Cabal-1.20.0.0:Distribution.Compiler.$wa3{v rKRZ} [gid] Cabal-1.20.0.0:Distribution.Compiler.parseCompilerFlavorCompat_compilerMap{v rKS0} [gid] Cabal-1.20.0.0:Distribution.Compiler.parseCompilerFlavorCompat_go{v rKS1} [gid] lvl{v rKS2} [gid] lvl1{v rKS3} [gid] lvl2{v rKS4} [gid] lvl3{v rKS5} [gid] lvl4{v rKS6} [gid] lvl5{v rKS7} [gid] lvl6{v rKS8} [gid] lvl7{v rKS9} [gid] lvl8{v rKSa} [gid] lvl9{v rKSb} [gid] lvl10{v rKSc} [gid] lvl11{v rKSd} [gid] lvl12{v rKSe} [gid] lvl13{v rKSf} [gid] lvl14{v rKSg} [gid] lvl15{v rKSh} [gid] lvl16{v rKSi} [gid] lvl17{v rKSj} [gid] lvl18{v rKSk} [gid] lvl19{v rKSl} [gid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 21:17:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 21:17:58 -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.f268d7a8e40065ba70b03b996fa941e3@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 GHC 7.8.3 segfaults: {{{ ... Configuring Cabal-1.20.0.0... Building Cabal-1.20.0.0... Preprocessing library Cabal-1.20.0.0... [ 1 of 78] Compiling Paths_Cabal ( dist/build/autogen/Paths_Cabal.hs, dist/build/Paths_Cabal.o ) [ 2 of 78] Compiling Distribution.TestSuite ( Distribution/TestSuite.hs, dist/build/Distribution/TestSuite.o ) [ 3 of 78] Compiling Distribution.Simple.PreProcess.Unlit ( Distribution/Simple/PreProcess/Unlit.hs, dist/build/Distribution/Simple/PreProcess/Unlit.o ) [ 4 of 78] Compiling Distribution.GetOpt ( Distribution/GetOpt.hs, dist/build/Distribution/GetOpt.o ) [ 5 of 78] Compiling Distribution.PackageDescription.Utils ( Distribution/PackageDescription/Utils.hs, dist/build/Distribution/PackageDescription/Utils.o ) [ 6 of 78] Compiling Distribution.Simple.CCompiler ( Distribution/Simple/CCompiler.hs, dist/build/Distribution/Simple/CCompiler.o ) [ 7 of 78] Compiling Distribution.Compat.ReadP ( Distribution/Compat/ReadP.hs, dist/build/Distribution/Compat/ReadP.o ) [ 8 of 78] Compiling Distribution.Text ( Distribution/Text.hs, dist/build/Distribution/Text.o ) [ 9 of 78] Compiling Distribution.Version ( Distribution/Version.hs, dist/build/Distribution/Version.o ) [10 of 78] Compiling Distribution.Compiler ( Distribution/Compiler.hs, dist/build/Distribution/Compiler.o ) ./bootstrap.sh: line 212: 27240 Segmentation fault (core dumped) ./Setup build ${EXTRA_BUILD_OPTS} ${VERBOSE} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 21:29:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 21:29:10 -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.a482c95e19b1450d738c972e8af93c20@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): However, 32-bit [https://downloads.haskell.org/~ghc/7.8.2/ghc-7.8.2-i386 -unknown-linux-centos65.tar.xz GHC 7.8.2] does '''not''' fail, and manages to bootstrap ''cabal-install'' 1.20.0.3 successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 21:56:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 21:56:51 -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.0d4e3989b6297f38a1d3800102fa1953@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: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc1 (other) | Keywords: Resolution: | Architecture: sparc Operating System: Solaris | Test Case: Type of failure: Building GHC | Blocking: failed | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by mietek): This also happens on 32-bit [https://aws.amazon.com/marketplace/pp/B00A6KZBC6/ CentOS 6.5] and 32-bit [https://aws.amazon.com/marketplace/pp/B007NMF9O0/ Red Hat Enterprise Linux 6.5], when attempting to install the GHC 7.10.1-rc2 bindist, at configure phase: {{{ checking for path to top of build tree... utils/ghc-pwd/dist- install/build/tmp/ghc-pwd: symbol lookup error: libraries/integer-gmp2 /dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi- ghc7.10.0.20150123.so: undefined symbol: __gmpn_andn_n }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 22:01:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 22:01:15 -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.4f6b4fd44ea4da36e445a696dd092758@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: new Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc1 (other) | Keywords: Resolution: | Architecture: sparc Operating System: Solaris | Test Case: Type of failure: Building GHC | Blocking: failed | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 22:03:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 22:03:48 -0000 Subject: [GHC] #9388: Narrow the scope of the notorious "state hack" In-Reply-To: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> References: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> Message-ID: <061.5e1e88f4cc009bf59ea0b13ff676dcba@haskell.org> #9388: Narrow the scope of the notorious "state hack" -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): I?m considering giving this one shot (pun intended), and I?m reading the current implementation of the state hack, and found some pretty old-dated comments, including this one from 2004 in `Id.hs`: {{{ -- Another good example is in fill_in in PrelPack.lhs. We should be able to -- spot that fill_in has arity 2 (and when Keith is done, we will) but we can't yet. }}} I do not know who Keith is, and why that would help, and most likely something about todays demand analyzer should be written there. Simon, if you have a minute, would you mind revisiting the comment at `isStateHack`? It would help whoever tackles the problem next. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 22:49:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 22:49:39 -0000 Subject: [GHC] #9388: Narrow the scope of the notorious "state hack" In-Reply-To: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> References: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> Message-ID: <061.362fa68a4717c5ad32b2339814a98145@haskell.org> #9388: Narrow the scope of the notorious "state hack" -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): Has someone implemented this without telling us? In GHC-7.8.4, compiling {{{ pr :: String -> IO () pr x = putStrLn (reverse x) }}} without the state hack yields {{{ pr = \ x_arX -> let s_aQl = reverse1 x_arX ([]) in (\ eta_aQm -> hPutStr2 stdout s_aQl True eta_aQm) `cast` ... }}} and only with the state hack, we get the good {{{ pr1 = \ x_arX eta_B1 -> hPutStr2 stdout (reverse x_arX) True eta_B1 }}} But with GHC HEAD, the output is good with and without `-fno-state-hack`. So either something implemented this, or the state hack flag gets ignored for some reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 21 23:22:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Feb 2015 23:22:42 -0000 Subject: [GHC] #9388: Narrow the scope of the notorious "state hack" In-Reply-To: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> References: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> Message-ID: <061.d6cdeafacef15651c705bef37a7081b6@haskell.org> #9388: Narrow the scope of the notorious "state hack" -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): Ah, I think it might have been me, at least partially: In `MkId`, the `realWorldPrimId` has `setOneShotInfo` stateHackOneShot set. This means that _every_ lambda with an argument of type `State#` is marked as oneshot. This was introduced in changeset:80989de/ghc ? maybe this bit was not even meant to be merged? Back then, the `OneShotInfo` would not be exported, so the unfolding for `hPutStr2` would say `(\ s ::String eta :: State# RealWorld -> ...` But when I added the `oneShot` magic function, I also made sure that the `OneShotInfo` would be written to the interface, so it now says `(\ s ::String eta :: State# RealWorld[oneShot] -> ...` and the simplifier will float in the call to `reverse`. I?ll rip out all state hack code (which seems to be implemented by `OneShotInfo` on `realWorldPrimId` and via `typeOneShot`) and see if I can achieve something similar in a cleaner way and only for top-level bindings in the cardinality analysis. It?s a nice weekend relaxation from paper proofreading :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 08:34:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 08:34:03 -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.d67aa8c068f290629f740c284bff11f7@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: new 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): I think I have a patch. I am currently validating. Now I get this for the test: {{{ singletons/tests/compile-and-dump> ghc -c -this-package-key singl_0TYtxGjPhBTAZuoSNyonA0 -i../../dist/build -XTemplateHaskell Singletons/Maybe.hs Singletons/Maybe.hs:9:3: Unexpected kind variable ?a_a4JS? Perhaps you intended to use PolyKinds In the declaration for type synonym ?SMaybe? Singletons/Maybe.hs:9:3: Illegal kind signature: ?Maybe_a4JP a_a4JS? Perhaps you intended to use KindSignatures In the declaration for type synonym ?SMaybe? Singletons/Maybe.hs:9:3: Unexpected kind variable ?a_a4JS? Perhaps you intended to use PolyKinds In the data type declaration for ?JustSym0? Singletons/Maybe.hs:9:3: Illegal kind signature: ?TyFun a_a4JS (Maybe_a4JP a_a4JS)? Perhaps you intended to use KindSignatures In the data type declaration for ?JustSym0? Singletons/Maybe.hs:9:3: Unexpected kind variable ?a_a4JS? Perhaps you intended to use PolyKinds In the declaration for type synonym ?JustSym1? Singletons/Maybe.hs:9:3: Illegal kind signature: ?a_a4JS? Perhaps you intended to use KindSignatures In the declaration for type synonym ?JustSym1? [...] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 08:39:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 08:39:41 -0000 Subject: [GHC] #10106: GHC doesn't warn on typos in language pragmas In-Reply-To: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> References: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> Message-ID: <060.3fe8a8fd8b359f74b64c7559e2cd06ae@haskell.org> #10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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: -------------------------------------+------------------------------------- Comment (by hvr): The problem is rather that the warning is suppressed if errors exist... if you comment out the quasiquote use site, you'd get a `Warning: Unrecognised pragma` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 11:56:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 11:56:03 -0000 Subject: [GHC] #7170: Foreign.Concurrent finalizer called twice in some cases In-Reply-To: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> References: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> Message-ID: <063.2032b0ee1fe6ff3cc1a39ab5520b86c6@haskell.org> #7170: Foreign.Concurrent finalizer called twice in some cases -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | ffi/should_run/7170 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * owner: ekmett => Comment: Relinquishing control over this ticket: It requires someone with a better grasp of the runtime issues than me, and having it assigned to me, may cause someone who could solve it to pass it by. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:01:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:01:44 -0000 Subject: [GHC] #806: hGetBufNonBlocking doesn't work on Windows In-Reply-To: <053.4faf11bcb1c323d37868059a7808a067@haskell.org> References: <053.4faf11bcb1c323d37868059a7808a067@haskell.org> Message-ID: <068.011296b81b4a376c5b7b837ed4564126@haskell.org> #806: hGetBufNonBlocking doesn't work on Windows -----------------------------------+------------------------------------- Reporter: titto@? | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: hGetBuf001 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) * owner: ekmett => Comment: Relinquishing ownership of this ticket as this seems to be more of a runtime system issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:02:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:02:43 -0000 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> References: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> Message-ID: <062.c9d963446d8b561509dd132b718a9a2a@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | hsetbuffering buffering buffer Type of failure: None/Unknown | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * owner: ekmett => Comment: Relinquishing ownership of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:06:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:06:05 -0000 Subject: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure In-Reply-To: <052.f68490df51931cf0218e339e7abda5be@haskell.org> References: <052.f68490df51931cf0218e339e7abda5be@haskell.org> Message-ID: <067.fb2785c8b66039917128531753c02f1c@haskell.org> #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------------+------------------------------------- Reporter: AntoineLatter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) * owner: ekmett => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:08:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:08:07 -0000 Subject: [GHC] #2408: threadWaitRead on mingw32 threaded causes internal error In-Reply-To: <044.646a5d9cf31ef2594dbfe492fec77132@haskell.org> References: <044.646a5d9cf31ef2594dbfe492fec77132@haskell.org> Message-ID: <059.34e93b220f448cbfddd9bd19ec2bcb29@haskell.org> #2408: threadWaitRead on mingw32 threaded causes internal error -----------------------------------+--------------------------------- Reporter: kirby | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+--------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) * owner: ekmett => Comment: Relinquishing ownership. This seems like a better project for the windows task force. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:10:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:10:51 -0000 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@haskell.org> References: <046.c71a4f69a48e7e64e18a56e29c643e03@haskell.org> Message-ID: <061.ebb532683dffc2361d8dd1597730384f@haskell.org> #3676: realToFrac doesn't sanely convert between floating types -------------------------------------+------------------------------------- Reporter: draconx | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.12.1 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: x86_64 Blocked By: | (amd64) Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * keywords: => report-impact Comment: Any action we take on this would have an effect on the Haskell Report. Noting this accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:13:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:13:15 -0000 Subject: [GHC] #5466: Documentation for Chan could be better In-Reply-To: <046.e46c035a91971e631614cfca8496f79e@haskell.org> References: <046.e46c035a91971e631614cfca8496f79e@haskell.org> Message-ID: <061.32e3c6921299768da54b20ceea351a53@haskell.org> #5466: Documentation for Chan could be better -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 7.2.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): On the plus side, at least the deprecations now show up in the haddocks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:27:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:27:39 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.03f50d46690726bbf23e8a1077db3280@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:28:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:28:40 -0000 Subject: [GHC] #7373: When building GHC: Failed to load interface for `GHC.Fingerprint' In-Reply-To: <044.db3e0e59ecd8b510e5d89167f1c75f88@haskell.org> References: <044.db3e0e59ecd8b510e5d89167f1c75f88@haskell.org> Message-ID: <059.978ef329b4e737f76d6d7895c7c5a4df@haskell.org> #7373: When building GHC: Failed to load interface for `GHC.Fingerprint' -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8975 | driver/T7373 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * owner: ekmett => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:29:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:29:45 -0000 Subject: [GHC] #10107: Add Functor etc. to Data.Monoid wrappers Message-ID: <045.31f9fd043cf1068180e128aefcf56dfc@haskell.org> #10107: Add Functor etc. to Data.Monoid wrappers -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature | Status: new request | Milestone: 7.12.1 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: | -------------------------------------+------------------------------------- Add Functor, Foldable, Traversable, Monad, Applicative, MonadFix and Data to wrappers in Data.Monoid Discussion on libraries list: https://mail.haskell.org/pipermail/libraries/2015-February/024989.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:30:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:30:37 -0000 Subject: [GHC] #7604: System.Directory.canonicalizePath "" behaviour differs between platforms In-Reply-To: <044.4e35e3e717d362d41588b9e1ae91fd1d@haskell.org> References: <044.4e35e3e717d362d41588b9e1ae91fd1d@haskell.org> Message-ID: <059.9724fe70c0c5f519594bf22bdceb5a66@haskell.org> #7604: System.Directory.canonicalizePath "" behaviour differs between platforms -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: T4113 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) Comment: Pushed upstream: https://github.com/haskell/directory/issues/21 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:36:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:36:10 -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.e9b9f59c02db0efe2fd91e38c29eba0e@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: | Blocking: | Differential Revisions: Phab:D673 -------------------------------------+------------------------------------- Changes (by phadej): * differential: => Phab:D673 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:43:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:43:34 -0000 Subject: [GHC] #4880: Functor, Monad, Applicative instances for Data.Monoid.First, Data.Monoid.Last In-Reply-To: <043.40e973f46a003a38ecb9f13d0d37e07c@haskell.org> References: <043.40e973f46a003a38ecb9f13d0d37e07c@haskell.org> Message-ID: <058.8b8d815adb8b455771cd791260ebf5c2@haskell.org> #4880: Functor, Monad, Applicative instances for Data.Monoid.First, Data.Monoid.Last -------------------------------------+------------------------------------- Reporter: sclv | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10107 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: => #10107 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:44:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:44:07 -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.0757307f6b926c72db07a2ba34a947a4@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 -------------------------------------+------------------------------------- Changes (by hvr): * related: => #4880 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:52:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:52:42 -0000 Subject: [GHC] #7634: MD5 collision could lead to SafeHaskell violation In-Reply-To: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> References: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> Message-ID: <061.588a0ca7970668ed67195f03bb8f6d51@haskell.org> #7634: MD5 collision could lead to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) * milestone: 7.12.1 => ? Comment: Acknowledging that this probably won't get addressed in the foreseeable future by pushing it out to _|_. Given that the two strings would have to be legal UTF-32 encodings of text that can actually be entered you wind up with a '''huge''' number of fixed bits in the strings on either side, which very quickly raises the cost of an attempted birthday attack and also forbids a number of birthday attack generation techniques. That said, saying a cryptographic attack isn't possible for hand-wavy reasons doesn't have a great track record for success. :) Techniques for finding small single block collisions via random walks, like https://eprint.iacr.org/2014/871.pdf are probably the most likely source of such a vulnerability. Notice how similar the colliding document pair are. In theory you could prune the walk to keep the paths always within the space of valid inputs. I lack a few weeks (months?) of HPC cluster time to test this hypothesis, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 12:54:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 12:54:00 -0000 Subject: [GHC] #7985: Allow openFile on unknown file type In-Reply-To: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> References: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> Message-ID: <064.ca299f16ac2f828c58fcceb94cfe7cb8@haskell.org> #7985: Allow openFile on unknown file type -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core Libraries | 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 ekmett): * owner: ekmett => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:01:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:01:56 -0000 Subject: [GHC] #9388: Narrow the scope of the notorious "state hack" In-Reply-To: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> References: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> Message-ID: <061.927c03e922fa01d64e5bed89610d05e7@haskell.org> #9388: Narrow the scope of the notorious "state hack" -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): I gave it a shot. The obvious place to make the demand analyzer believe that something of type `IO` is going to be called at most once is by adjusting `body_dmd` in `dmdAnalRhs`, similarly to `[Product demands for function body]`. The branch `wip/T9388` contains patches that remove the old state hack and introduce this one. On first glance, it seems to work. At least the bug in #10102 does not occur any more. Overall, it has a negative effect on performance (at least on bytes allocated): nofib?s `fibheaps` regresses by `16.7%`, `banner` by `12.4%` and `hpg` by `7.1%`, rewrite by `5.8%`. Others improve: `k-nucleotide` by `5%`. Geometric mean is a regression by `0.4%`. A quick diff of fibheap?s core shows large changes, which I did not investigate further. The branch validates, with the exception of a number of compiler performance benchmarks (T9203 haddock.Cabal haddock.base T5030 T5631 T9872c T9872a T5642 T9020 T3064 T9872d T9872b T1969), where allocation increases by up to 30%. So real world programs run better with the old state hack. In a way that is expected: Eta expansion is usually a good thing, even if cannot see that a the lambda is indeed one-shot. And even if it is not really one-shot, the benefits of eta-expansion might, in some cases, outweigh the cost of lost sharing. Only in a few (uncommon?) cases, e.g. replicate with a large number, it really hurts. I?m surprised that no test case starts to fail, and no known-to-fail test case suddenly passes; it seems that we have little coverage on the desired and/or unwanted effects of the state hack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:07:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:07:52 -0000 Subject: [GHC] #8362: Filesystem related tests failed on solaris (SmartOS) In-Reply-To: <045.1583030feb3ddc515a1e21f0a79caa57@haskell.org> References: <045.1583030feb3ddc515a1e21f0a79caa57@haskell.org> Message-ID: <060.a73d887698cd28c6b7faf4c372b182fb@haskell.org> #8362: Filesystem related tests failed on solaris (SmartOS) -------------------------------------+------------------------------------- Reporter: leroux | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) Comment: Not sure how much this issue has bitrotted in the meantime, but: * `user001` and `processGroup` seem to be a legitimate issues. Something went wrong in each of them. * The `posix005` failure appears to just be that the `setEnv` call puts the new environment variable at the other end of the environment on `SmartOS`. This test in particular could be made more stable by sorting the results, because it is currently testing unspecified details of the system call. * The `getPermissions001` failure appears to be that the `getPermissions001.hs` source file was checked out with execute permissions? * `hClose002` looks to be a minor wording difference? {{{ -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) +Left hClose002.tmp: hClose: invalid argument (Bad file number) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:09:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:09:39 -0000 Subject: [GHC] #8362: Filesystem related tests failed on solaris (SmartOS) In-Reply-To: <045.1583030feb3ddc515a1e21f0a79caa57@haskell.org> References: <045.1583030feb3ddc515a1e21f0a79caa57@haskell.org> Message-ID: <060.105f12d2cba9eb689595182b5b5fbec8@haskell.org> #8362: Filesystem related tests failed on solaris (SmartOS) -------------------------------------+------------------------------------- Reporter: leroux | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * owner: ekmett => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:12:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:12:25 -0000 Subject: [GHC] #8859: import conditionalization in System.Posix.Files.Common is wrong In-Reply-To: <047.ea86c023b4962335e095d1f92b0177e9@haskell.org> References: <047.ea86c023b4962335e095d1f92b0177e9@haskell.org> Message-ID: <062.1df2c9b3c9833def3fe3a38ee3d81403@haskell.org> #8859: import conditionalization in System.Posix.Files.Common is wrong -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Other | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) Comment: Passed upstream as https://github.com/haskell/unix/issues/36 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:15:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:15:27 -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.db02c82e0d16af687dfdf979942eb59a@haskell.org> #9044: createDirectoryIfMissing does not fail on unwritable parent dir -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | 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): * cc: core-libraries-committee@? (added) Comment: Pushed upstream: https://github.com/haskell/directory/issues/22 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:23:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:23:03 -0000 Subject: [GHC] #9079: Foreign.C.Types in haskell2010 In-Reply-To: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> References: <046.0c2f3309095eee33947f42c0af9aa93f@haskell.org> Message-ID: <061.ffb28df0d8579a272ef3245bea4e99bb@haskell.org> #9079: Foreign.C.Types in haskell2010 -------------------------------------+------------------------------------- Reporter: tensor5 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 ekmett): We've dropped core library support for the `haskell2010` package, due to #9590, but this still seems actionable. Herbert has been exploring ways to get users who really want it a fully compliant `haskell2010` package, and this unfortunate contradiction seems like it'd still impact his efforts on that front. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:26:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:26:04 -0000 Subject: [GHC] #9631: Comment in GHC.Base about GHC.Prim does not appear to be correct In-Reply-To: <045.cbd722b3600402ea72fb22a56a8d8e08@haskell.org> References: <045.cbd722b3600402ea72fb22a56a8d8e08@haskell.org> Message-ID: <060.81e7a02ebb9a432a72307e1f7c390bc4@haskell.org> #9631: Comment in GHC.Base about GHC.Prim does not appear to be correct -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:31:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:31:37 -0000 Subject: [GHC] #10092: lex doesn't handle binary literals In-Reply-To: <050.36d0be4204ee95d5f9c78410dc1eb92c@haskell.org> References: <050.36d0be4204ee95d5f9c78410dc1eb92c@haskell.org> Message-ID: <065.1ca69cc2185a9cb14cafaae03aab63b7@haskell.org> #10092: lex doesn't handle binary literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | BinaryLiterals report-impact Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9224 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Given that `read` and `show` should have portable behavior across implementations, it seems to me that we should _not_ support binary literals in `read`/`lex`. Otherwise we invite the endless waves of portability problems that ensue from the "be liberal in what you accept, strict in what you output" dogma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:41:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:41:42 -0000 Subject: [GHC] #4215: canonicalizePath behaves strangely with paths that do not exist In-Reply-To: <047.bec475e57d7633f29981b0c1afde7835@haskell.org> References: <047.bec475e57d7633f29981b0c1afde7835@haskell.org> Message-ID: <062.9b8cae44993a4bd8f12b5facbea1ab05@haskell.org> #4215: canonicalizePath behaves strangely with paths that do not exist -------------------------------------+------------------------------------- Reporter: creswick | Owner: ekmett Type: bug | Status: upstream Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 6.12.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: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) * status: new => upstream Comment: Submitted upstream: https://github.com/haskell/directory/issues/23 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:45:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:45:42 -0000 Subject: [GHC] #4861: Documentation for base does not include special items In-Reply-To: <051.5ee4c1527610ef4964c665e655014652@haskell.org> References: <051.5ee4c1527610ef4964c665e655014652@haskell.org> Message-ID: <066.734034bfa96c069f2dde1ad41c31cb5c@haskell.org> #4861: Documentation for base does not include special items -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: ekmett Type: bug | Status: upstream Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) * status: new => upstream Comment: Submitted upstream to haddock: https://github.com/haskell/haddock/issues/368 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 13:49:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 13:49:29 -0000 Subject: [GHC] #5014: canonicalizePath throws exception on paths that do not exist In-Reply-To: <048.38fed68301267b4479d1736f2f71b59d@haskell.org> References: <048.38fed68301267b4479d1736f2f71b59d@haskell.org> Message-ID: <063.87c821af397fec9352924914163b21a6@haskell.org> #5014: canonicalizePath throws exception on paths that do not exist -------------------------------------+------------------------------------- Reporter: hesselink | Owner: ekmett Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 7.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4215 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@? (added) * related: => #4215 Comment: #4215 seems related -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 14:45:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 14:45:45 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.790a8b743ca61afed434e3ba896dabb7@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | 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: Phab:D313 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"1f60d635cee1ff3db72e0129f9035b147f52c9c4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1f60d635cee1ff3db72e0129f9035b147f52c9c4" {Data,Generic(1),MonadZip} instances for Identity These instances were missed when the identity functor was added to the `base` package (re #9664). Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D674 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 16:52:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 16:52:54 -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.4fd0e5c8a39bfc5b41295f86d5e0a976@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: new Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc1 (other) | Keywords: Resolution: | Architecture: sparc Operating System: Solaris | Test Case: Type of failure: Building GHC | Blocking: failed | Differential Revisions: Phab:675 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:675 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 16:53:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 16:53:24 -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.cd1773a38a0440f913e4aee11677a564@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: new Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc1 (other) | Keywords: Resolution: | Architecture: sparc Operating System: Solaris | Test Case: Type of failure: Building GHC | Blocking: failed | Differential Revisions: Phab:D675 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by hvr): * differential: Phab:675 => Phab:D675 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 16:55:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 16:55:38 -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.1cd06933c1da0c528267bd8979272e81@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: patch Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc1 (other) | Keywords: Resolution: | Architecture: sparc Operating System: Solaris | Test Case: Type of failure: Building GHC | Blocking: failed | Differential Revisions: Phab:D675 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 17:02:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 17:02:20 -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.2a91f44183458d8ae3f316957f0f9c59@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler Type: bug | Status: new 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: | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Changes (by trommler): * differential: => Phab:D676 Comment: Phab:D676 fixes this ticket but not the issue mentioned in comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 17:02:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 17:02:42 -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.599e25d0a5a86066ba30a34ca82331fa@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler 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: | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 17:22:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 17:22:26 -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.5921e442d8da5a10d7db5f84bfd6caaf@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler 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: | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:9 trommler]: > Now I get this for the test: The errors there are expected. In the actual testsuite, the testsuite driver specifies a whole lot of extensions on the command line. These weren't needed to tickle the panic, so I didn't include them in the instructions. However, if the comment:1 issue isn't fixed, I think there's more work to be done here, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 17:28:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 17:28:06 -0000 Subject: [GHC] #4366: in-tree GMP build problem with shared libraries In-Reply-To: <047.12130d9e1e414d6d645604d6c8a9c91d@haskell.org> References: <047.12130d9e1e414d6d645604d6c8a9c91d@haskell.org> Message-ID: <062.49ceff6ded1319a4921ec9fea8402ff1@haskell.org> #4366: in-tree GMP build problem with shared libraries -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Build System | Version: 6.13 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed * milestone: 7.12.1 => 7.10.1 Comment: I believe this issue to be fixed with GHC 7.10.1's `integer-gmp2` (see #9281); if this is still a problem, please reopen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 18:26:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 18:26:28 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.36540a4ed3363057063cce01c50e6e19@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #5666 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nsch): I actually ran into the same error on Windows 8.1 with GHC 7.8.3 (and gcc 4.6.3) from the Haskell Platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 18:27:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 18:27:32 -0000 Subject: [GHC] #10108: Dramatic slowdown with -O2 bytestream and list streams combined. Message-ID: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> #10108: Dramatic slowdown with -O2 bytestream and list streams combined. -------------------------------------+------------------------------------- Reporter: Truman | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: break_in.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In a small testcase intended to filter log files from stdin, I found that using bytestreams and list streams in combination worked fine when compiled without optimization, but runtime performance slowed down by a factor of about 3600 when I compiled with -O2. Changing the import of Data.List.Stream to Data.List gets rid of the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 18:29:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 18:29:12 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.e5ec7ac51b7d0a409c5879ef4dab58f6@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #5666 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nsch): * cc: mail@? (added) * version: 7.6.3 => 7.8.3 * os: OpenBSD => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 19:02:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 19:02:17 -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.861ebfa0506f72605232c161352281b0@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler 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: | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:12 goldfire]: > However, if the comment:1 issue isn't fixed, I think there's more work to be done here, no? I would like to open a new ticket for the issue in comment:1 because I think it is a different issue. The undefined symbol in this ticket is in another package whereas in comment:1 it is found in one of the objects of the current package. That symbol, however, should be resolvable by linking with the previous temporary shared object and following the chain of links to the module where the symbol is defined. My current hypothesis is some Linux distributions modify the defaults of GNU `ld` (and perhaps Gold) and that is responsible for the undefined symbol. The fix that I have in mind involves checking for a link editor flag called `--no-as-needed` (and it must be the link editor we use in the installed ghc) and then passing the correct flag to override the default. See: https://ghc.haskell.org/trac/ghc/ticket/9186#comment:26 for more details on that flag. The issue does not affect OSX. That would reduce the scope of the defect to only those systems that have a modified` ld` , i.e. some Linux distributions. I'll create a new ticket with more details tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 20:37:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 20:37:40 -0000 Subject: [GHC] #10106: GHC doesn't warn on typos in language pragmas In-Reply-To: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> References: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> Message-ID: <060.ea13263f8ecefd33173a6293123a49de@haskell.org> #10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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: -------------------------------------+------------------------------------- Comment (by sdemos): I tested that out with my code, and it does indeed print out the `Warning: Unrecognized pragma` warning. However, I think it would be better for debugging this type of issue if it didn't suppress the warning, or gave a hint that the unrecognized pragma might be the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 20:50:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 20:50:09 -0000 Subject: [GHC] #7604: System.Directory.canonicalizePath "" behaviour differs between platforms In-Reply-To: <044.4e35e3e717d362d41588b9e1ae91fd1d@haskell.org> References: <044.4e35e3e717d362d41588b9e1ae91fd1d@haskell.org> Message-ID: <059.cef8537b05baadca7f045a4881293d6f@haskell.org> #7604: System.Directory.canonicalizePath "" behaviour differs between platforms -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: T4113 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by argiopeweb): * status: new => closed * resolution: => fixed * milestone: 7.12.1 => 7.10.1 Comment: Calling `canonicalizePath` on an empty string now explicitly returns the result of calling `canonicalizePath` on the current directory (".") as in OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 22 22:05:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Feb 2015 22:05:16 -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.2c0e7aa3ffb86716c2ca791d75845e03@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: patch 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: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 00:49:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 00:49:42 -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.0acdb08cf730044a34bae6ba21217f95@haskell.org> #10058: Panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: trommler 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: | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Comment (by goldfire): Ah -- I understand just enough of that to see why you want a new ticket. Thanks much for taking a look at this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 00:51:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 00:51:50 -0000 Subject: [GHC] #10076: Don't suppress warnings in the presence of errors In-Reply-To: <048.07984c34d4e400833c1a386400621378@haskell.org> References: <048.07984c34d4e400833c1a386400621378@haskell.org> Message-ID: <063.12b448951adcdf8488cbccba72179b76@haskell.org> #10076: Don't suppress warnings in the presence of errors -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 goldfire): For another motivating example, see #10106. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 07:14:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 07:14:16 -0000 Subject: [GHC] #10106: GHC doesn't warn on typos in language pragmas In-Reply-To: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> References: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> Message-ID: <060.1662cf86134f6aefa9001aa7e2c1a724@haskell.org> #10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #10076 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #10076 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 07:38:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 07:38:37 -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.7cfbda1c62a9926b784e037be9922b4c@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 simonpj): Yes indeed: see the https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html user manual]. At least it no longer loops! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 08:31:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 08:31:25 -0000 Subject: [GHC] #7634: MD5 collision could lead to SafeHaskell violation In-Reply-To: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> References: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> Message-ID: <061.beab483950acc6006843c0176f17d039@haskell.org> #7634: MD5 collision could lead to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bananu7): > Maybe the solution is just switching to another hash function What about that? Doesn't that improve the ''chances'' of the collision not being found even more? It looks like an change that's easy enough. Doesn't moving this ticket to _|_ mean that it's effectively being forgotten? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 08:32:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 08:32:48 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.b9151cc5c0426a0e9e42253af7183362@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: #8634 | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed Comment: Replying to [comment:13 simonpj]: > But as you'll see with `-fprint-explicit-kinds`, the coverage condition really is violated. I'm looking at the error message with `-fprint-explicit-kinds` and I don't see how the coverage condition is violated here :-/ {{{ Illegal instance declaration for ?Add * k * (Succ k a) b (Succ k ab)? The liberal coverage condition fails in class ?Add? for functional dependency: ?a b -> ab? Reason: lhs types ?Succ k a?, ?b? do not jointly determine rhs type ?Succ k ab? In the instance declaration for ?Add (Succ a) b (Succ ab)? }}} But if you say this is correct then I trust your judgement. Closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 08:33:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 08:33:50 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.25b42a72fac4eaa9146b8dde2e7329cf@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: #8634 | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: closed => new * resolution: fixed => Comment: Wrong resolution, sorry. Reopening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 08:34:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 08:34:22 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.60007c09e2156ce5e348bd0138bd89d2@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8634 | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => invalid Comment: ...and closing as invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:25:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:25:47 -0000 Subject: [GHC] #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) In-Reply-To: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> References: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> Message-ID: <061.ec1ce607c22dd660a0ca0cbab2791977@haskell.org> #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) ----------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Comment (by Karel Gardas ): In [changeset:"b2be772a97f6e7fe9f1d1c28108949f81a13158b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b2be772a97f6e7fe9f1d1c28108949f81a13158b" fix bus errors on SPARC caused by unalignment access to alloc_limit (fixes #10043) Reviewers: austin, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D657 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:16 -0000 Subject: [GHC] #7765: Odd error message for `runghc` with missing `main` function. In-Reply-To: <050.8542064156faf46af950f88e560aca22@haskell.org> References: <050.8542064156faf46af950f88e560aca22@haskell.org> Message-ID: <065.9b0426e671e5bf888dc20a1da6b575e4@haskell.org> #7765: Odd error message for `runghc` with missing `main` function. -------------------------------------+------------------------------------- Reporter: isaacdupree | Owner: Type: bug | Status: patch 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: #414 | module/T7765 | Blocking: | Differential Revisions: Phab:D649 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"0fa20726b0587530712677e50a56c2b03ba43095/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0fa20726b0587530712677e50a56c2b03ba43095" Error out on `Main` without `main` in GHCi (#7765) Summary: GHC does 2 validation checks for module `Main`: * does `main` exist * is `main` exported (#414) The second check is done in ghc as well as in ghci (and runghc and ghc -e). The first check however is currently not done in ghci, to prevent "'main' is not in scope" errors when loading simple scripts. See commit d28ba8c8009 for more information. This commit tightens the special case for ghci. When the file does not contain a main function, but does contain an explicit module header (i.e. "module Main where"), then /do/ raise an error in ghci (and runghc and ghc -e) as well Test Plan: module/T7765: a module Main with an explicit module header but without a main function should be an error for all Ways. Additionaly: delete test module/mod174. It was added in commit 5a54c38, but it is a duplicate of module/T414. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D649 GHC Trac Issues: #7765 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:16 -0000 Subject: [GHC] #10096: Top-level ./configure should accept and propagate --with-curses-{includes, libraries} to libraries In-Reply-To: <042.c3039c780bf240b53edd532cee07dad0@haskell.org> References: <042.c3039c780bf240b53edd532cee07dad0@haskell.org> Message-ID: <057.396a2728f210af1356e2ac7e3fccba20@haskell.org> #10096: Top-level ./configure should accept and propagate --with- curses-{includes,libraries} to libraries -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7472 | Blocking: | Differential Revisions: Phab:D665 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"bbb57a6b3a31c22a5a24fa4b92abbe13a6736ad8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bbb57a6b3a31c22a5a24fa4b92abbe13a6736ad8" Make top-level "configure" accept and propagate --with- curses-{includes,libraries} to libraries Summary: If curses is installed into some non-standard path, we currently have to say something like the following in mk/build.mk: libraries/terminfo_CONFIGURE_OPTS += \ --configure-option=--with-curses-includes=/somewhere/include \ --configure-option=--with-curses-libraries=/somewhere/lib This is because the top-level configure does not accept nor propagate --with-curses-{includes,libraries} to libraries while it does so for iconv, gmp and libffi. It would be nice if curses were handled in the same manner. Test Plan: Install curses into some non-standard path. Then run the top- level "configure" script with options "--with-curses- includes=/path/to/curses/include" and "--with-curses- libraries=/path/to/curses/lib". Reviewers: austin Reviewed By: austin Subscribers: thomie, PHO Differential Revision: https://phabricator.haskell.org/D665 GHC Trac Issues: #10096 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:16 -0000 Subject: [GHC] #414: GHC does not eforce that Main exports main In-Reply-To: <046.38fe8da23abfc42f9ad2cb0e14b8afda@haskell.org> References: <046.38fe8da23abfc42f9ad2cb0e14b8afda@haskell.org> Message-ID: <061.da64088f0c4ce26926ed3fff07caac07@haskell.org> #414: GHC does not eforce that Main exports main -------------------------------------+------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: lowest | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | module/T414 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"0fa20726b0587530712677e50a56c2b03ba43095/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0fa20726b0587530712677e50a56c2b03ba43095" Error out on `Main` without `main` in GHCi (#7765) Summary: GHC does 2 validation checks for module `Main`: * does `main` exist * is `main` exported (#414) The second check is done in ghc as well as in ghci (and runghc and ghc -e). The first check however is currently not done in ghci, to prevent "'main' is not in scope" errors when loading simple scripts. See commit d28ba8c8009 for more information. This commit tightens the special case for ghci. When the file does not contain a main function, but does contain an explicit module header (i.e. "module Main where"), then /do/ raise an error in ghci (and runghc and ghc -e) as well Test Plan: module/T7765: a module Main with an explicit module header but without a main function should be an error for all Ways. Additionaly: delete test module/mod174. It was added in commit 5a54c38, but it is a duplicate of module/T414. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D649 GHC Trac Issues: #7765 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:16 -0000 Subject: [GHC] #10078: tcPluginStop of a type checker plugin is not called if an error occurs In-Reply-To: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> References: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> Message-ID: <062.79b9bf1d12c95c72ee42a53b5a52d168@haskell.org> #10078: tcPluginStop of a type checker plugin is not called if an error occurs -------------------------------------+------------------------------------- Reporter: jbracker | Owner: jbracker Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"fd581a7300abede9a070cb6e9b835b2e18f68b0b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fd581a7300abede9a070cb6e9b835b2e18f68b0b" Fix for ticket #10078: ensure that tcPluginStop is called even in case of type errors Summary: Remove unused variable that appeared through the fix for ticket #10078 Merge branch 'master' of git://git.haskell.org/ghc Added comment with bug ID. Reviewers: adamgundry, gridaphobe, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D667 GHC Trac Issues: #10078 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:16 -0000 Subject: [GHC] #10051: panic - the 'impossible' happened In-Reply-To: <046.81c18ed44b1067fab64df95400149350@haskell.org> References: <046.81c18ed44b1067fab64df95400149350@haskell.org> Message-ID: <061.c385d67ec565723ae57cd797145960ef@haskell.org> #10051: panic - the 'impossible' happened ---------------------------------+----------------------------------------- Reporter: jpw1991 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #9907 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by Austin Seipp ): In [changeset:"a293925d810229fbea77d95f2b3068e78f8380cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a293925d810229fbea77d95f2b3068e78f8380cc" rts/linker: ignore unknown PE sections Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed. Test Plan: See the file `ghcilinkerbug.zip` in #9907. 1) unzip file content. 2) open examplecpp.cabal and change base <4.8 to <4.9. 3) execute cabal file with cabal repl. Applying the patch makes `cabal repl` in step 3) work. Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D671 GHC Trac Issues: #9907, #7103, #10051, #7056, #8546 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:16 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.2be1eb71c21400f1ae5b48a9104e3b33@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: D671 #7056, #8546 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a293925d810229fbea77d95f2b3068e78f8380cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a293925d810229fbea77d95f2b3068e78f8380cc" rts/linker: ignore unknown PE sections Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed. Test Plan: See the file `ghcilinkerbug.zip` in #9907. 1) unzip file content. 2) open examplecpp.cabal and change base <4.8 to <4.9. 3) execute cabal file with cabal repl. Applying the patch makes `cabal repl` in step 3) work. Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D671 GHC Trac Issues: #9907, #7103, #10051, #7056, #8546 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:17 -0000 Subject: [GHC] #8546: Panic during cabal build with profiling enabled. In-Reply-To: <046.19ad90151657537b62338ee47b7c0085@haskell.org> References: <046.19ad90151657537b62338ee47b7c0085@haskell.org> Message-ID: <061.191ba380ae4cdb16b916d9e6cbe2046b@haskell.org> #8546: Panic during cabal build with profiling enabled. -------------------------------------+------------------------------------- Reporter: Mokosha | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: cabal Operating System: Windows | sandbox Type of failure: Compile-time | Architecture: x86 crash | Test Case: Blocked By: | Blocking: Related Tickets: #7056 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a293925d810229fbea77d95f2b3068e78f8380cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a293925d810229fbea77d95f2b3068e78f8380cc" rts/linker: ignore unknown PE sections Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed. Test Plan: See the file `ghcilinkerbug.zip` in #9907. 1) unzip file content. 2) open examplecpp.cabal and change base <4.8 to <4.9. 3) execute cabal file with cabal repl. Applying the patch makes `cabal repl` in step 3) work. Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D671 GHC Trac Issues: #9907, #7103, #10051, #7056, #8546 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:17 -0000 Subject: [GHC] #10104: Show '#' on unboxed literals In-Reply-To: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> References: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> Message-ID: <060.470cb789135b7cd6e60d1463854aa032@haskell.org> #10104: Show '#' on unboxed literals -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: patch 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: #8274 | deriving/should_run/T10104 | Blocking: | Differential Revisions: Phab:D672 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"47175e06ff8364c732607e3d76ef3b7b80d57f1c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="47175e06ff8364c732607e3d76ef3b7b80d57f1c" Show '#' on unboxed literals Test Plan: deriving/should_run/T10104 Reviewers: austin, jstolarek Reviewed By: austin, jstolarek Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D672 GHC Trac Issues: #10104 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:17 -0000 Subject: [GHC] #7103: Compiler panic, when loading wxc in GHCi In-Reply-To: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> References: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> Message-ID: <062.939c29afbeeab9a1a2a18a2bdad35ec4@haskell.org> #7103: Compiler panic, when loading wxc in GHCi -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: 3658 | Test Case: Related Tickets: #9907, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a293925d810229fbea77d95f2b3068e78f8380cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a293925d810229fbea77d95f2b3068e78f8380cc" rts/linker: ignore unknown PE sections Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed. Test Plan: See the file `ghcilinkerbug.zip` in #9907. 1) unzip file content. 2) open examplecpp.cabal and change base <4.8 to <4.9. 3) execute cabal file with cabal repl. Applying the patch makes `cabal repl` in step 3) work. Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D671 GHC Trac Issues: #9907, #7103, #10051, #7056, #8546 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:40:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:40:16 -0000 Subject: [GHC] #7056: Relax static-PE linker object checks In-Reply-To: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> References: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> Message-ID: <060.02d690b1d4acbc57128169be9ab05d98@haskell.org> #7056: Relax static-PE linker object checks -------------------------------------+------------------------------------- Reporter: songpp | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown Operating System: Windows | PEi386 Type of failure: None/Unknown | Architecture: x86 Blocked By: | Test Case: Related Tickets: #2487, #7103, | Blocking: #7889 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a293925d810229fbea77d95f2b3068e78f8380cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a293925d810229fbea77d95f2b3068e78f8380cc" rts/linker: ignore unknown PE sections Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed. Test Plan: See the file `ghcilinkerbug.zip` in #9907. 1) unzip file content. 2) open examplecpp.cabal and change base <4.8 to <4.9. 3) execute cabal file with cabal repl. Applying the patch makes `cabal repl` in step 3) work. Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D671 GHC Trac Issues: #9907, #7103, #10051, #7056, #8546 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:41:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:41:18 -0000 Subject: [GHC] #10104: Show '#' on unboxed literals In-Reply-To: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> References: <045.d39d4d8515449a6ef3ec5608fb1f3eaf@haskell.org> Message-ID: <060.7624f9ccf74509af428f0923cf3f7226@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 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * type: feature request => bug * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:42:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:42:21 -0000 Subject: [GHC] #10078: tcPluginStop of a type checker plugin is not called if an error occurs In-Reply-To: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> References: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> Message-ID: <062.e39e0a6ad207e29d00610192f4e27a1c@haskell.org> #10078: tcPluginStop of a type checker plugin is not called if an error occurs -------------------------------------+------------------------------------- Reporter: jbracker | Owner: jbracker Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:42:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:42:35 -0000 Subject: [GHC] #10096: Top-level ./configure should accept and propagate --with-curses-{includes, libraries} to libraries In-Reply-To: <042.c3039c780bf240b53edd532cee07dad0@haskell.org> References: <042.c3039c780bf240b53edd532cee07dad0@haskell.org> Message-ID: <057.757029b843b83fe9ac35b483efc941ad@haskell.org> #10096: Top-level ./configure should accept and propagate --with- curses-{includes,libraries} to libraries -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: feature request | Status: merge Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7472 | Blocking: | Differential Revisions: Phab:D665 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:43:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:43:01 -0000 Subject: [GHC] #7765: Odd error message for `runghc` with missing `main` function. In-Reply-To: <050.8542064156faf46af950f88e560aca22@haskell.org> References: <050.8542064156faf46af950f88e560aca22@haskell.org> Message-ID: <065.2cfc8a6eddb87e0c3120d465d971f4b5@haskell.org> #7765: Odd error message for `runghc` with missing `main` function. -------------------------------------+------------------------------------- Reporter: isaacdupree | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #414 | module/T7765 | Blocking: | Differential Revisions: Phab:D649 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:44:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:44:40 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.51309d329092418b2a1fabd69c563d1c@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge * differential: D671 => Phab:D671 * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:49:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:49:49 -0000 Subject: [GHC] #7103: Compiler panic, when loading wxc in GHCi In-Reply-To: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> References: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> Message-ID: <062.71bbc28f5fd2e6e877d3d93074c2483e@haskell.org> #7103: Compiler panic, when loading wxc in GHCi -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9907, #10051, | Blocking: #7056, #8546 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => duplicate * related: #9907, #10051 => #9907, #10051, #7056, #8546 * blockedby: 3658 => * milestone: 7.12.1 => 7.10.1 Comment: Duplicate of #9907, which will be merged to 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:49:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:49:58 -0000 Subject: [GHC] #10051: panic - the 'impossible' happened In-Reply-To: <046.81c18ed44b1067fab64df95400149350@haskell.org> References: <046.81c18ed44b1067fab64df95400149350@haskell.org> Message-ID: <061.dbb893823cf7acad88eda009e02732f5@haskell.org> #10051: panic - the 'impossible' happened -------------------------------------+------------------------------------- Reporter: jpw1991 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHCi crash | (amd64) Blocked By: | Test Case: Related Tickets: #9907, #7103, | Blocking: #7056, #8546 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => duplicate * related: #7103, #9907 => #9907, #7103, #7056, #8546 Comment: Duplicate of #9907, which will be merged to 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:50:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:50:05 -0000 Subject: [GHC] #8546: Panic during cabal build with profiling enabled. In-Reply-To: <046.19ad90151657537b62338ee47b7c0085@haskell.org> References: <046.19ad90151657537b62338ee47b7c0085@haskell.org> Message-ID: <061.d36759514f1873c60775847d289e0c02@haskell.org> #8546: Panic during cabal build with profiling enabled. -------------------------------------+------------------------------------- Reporter: Mokosha | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: cabal Operating System: Windows | sandbox Type of failure: Compile-time | Architecture: x86 crash | Test Case: Blocked By: | Blocking: Related Tickets: #9907, #7103, | Differential Revisions: #10051, #7056 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * related: #7056 => #9907, #7103, #10051, #7056 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:50:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:50:05 -0000 Subject: [GHC] #7056: Relax static-PE linker object checks In-Reply-To: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> References: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> Message-ID: <060.353cdb45f4d4dc11fb2d22822f4db7b3@haskell.org> #7056: Relax static-PE linker object checks -------------------------------------+------------------------------------- Reporter: songpp | Owner: Type: bug | thoughtpolice Priority: normal | Status: closed Component: GHCi | Milestone: 7.10.1 Resolution: duplicate | Version: 7.4.1 Operating System: Windows | Keywords: Type of failure: None/Unknown | loadArchive Unknown PEi386 Blocked By: | Architecture: x86 Related Tickets: #9907, #2487, | Test Case: #7103, #7889, #8546 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => duplicate * related: #2487, #7103, #7889 => #9907, #2487, #7103, #7889, #8546 * milestone: 7.12.1 => 7.10.1 Comment: Duplicate of #9907, which will be merged to 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:50:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:50:15 -0000 Subject: [GHC] #10051: panic - the 'impossible' happened In-Reply-To: <046.81c18ed44b1067fab64df95400149350@haskell.org> References: <046.81c18ed44b1067fab64df95400149350@haskell.org> Message-ID: <061.4c6d0308b17a3bc9f9fb6108d784a02b@haskell.org> #10051: panic - the 'impossible' happened -------------------------------------+------------------------------------- Reporter: jpw1991 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHCi crash | (amd64) Blocked By: | Test Case: Related Tickets: #9907, #7103, | Blocking: #7056, #8546 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:55:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:55:20 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.f8c801fd7604686e27abd48a5edb0894@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via ad628657cd56362964d17677728f4ae4d6868613). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:55:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:55:55 -0000 Subject: [GHC] #10078: tcPluginStop of a type checker plugin is not called if an error occurs In-Reply-To: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> References: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> Message-ID: <062.b56258ba2419d63370775d8900583164@haskell.org> #10078: tcPluginStop of a type checker plugin is not called if an error occurs -------------------------------------+------------------------------------- Reporter: jbracker | Owner: jbracker Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via f163b15ce15cbe6ce19e168efde400a630cbf8b1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:56:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:56:05 -0000 Subject: [GHC] #10096: Top-level ./configure should accept and propagate --with-curses-{includes, libraries} to libraries In-Reply-To: <042.c3039c780bf240b53edd532cee07dad0@haskell.org> References: <042.c3039c780bf240b53edd532cee07dad0@haskell.org> Message-ID: <057.b69ad1c34499370c9ba75b28c1c16893@haskell.org> #10096: Top-level ./configure should accept and propagate --with- curses-{includes,libraries} to libraries -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7472 | Blocking: | Differential Revisions: Phab:D665 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via d9e24f4eb1f214a59f1d7d8a2535b1b255a45a51). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 09:59:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 09:59:46 -0000 Subject: [GHC] #10072: Panic: generalised wildcards in RULES In-Reply-To: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> References: <046.787fbd398d03bd8a24f1ac107c0bc87d@haskell.org> Message-ID: <061.9f2fe09114edacc3b1059cc506b415b4@haskell.org> #10072: Panic: generalised wildcards in RULES -------------------------------------+------------------------------------- Reporter: thomasw | Owner: thomasw Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/T10072 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged to `ghc-7.10` (via 20ccf72614bab9a00767b2514b7cded4b6e3084e). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 10:05:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 10:05:22 -0000 Subject: [GHC] #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) In-Reply-To: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> References: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> Message-ID: <061.8f310fc0a85c9b66565a41217cff852f@haskell.org> #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) ----------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Changes (by kgardas): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:04:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:04:30 -0000 Subject: [GHC] #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) In-Reply-To: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> References: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> Message-ID: <061.4c0be40027ff19c3f0bce7e18f3d0a71@haskell.org> #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) ----------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged to `ghc-7.10` (via 44c354d5e49187c8dda697b2d293931375f01709). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:14:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:14:26 -0000 Subject: [GHC] #10091: Add configurable verbosity level to hpc executable In-Reply-To: <044.9bf53187879824adb106c81d41020873@haskell.org> References: <044.9bf53187879824adb106c81d41020873@haskell.org> Message-ID: <059.6a443c04e71aceec8b6853b85f3f463a@haskell.org> #10091: Add configurable verbosity level to hpc executable -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | Status: merge Priority: normal | Milestone: 7.10.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: Related Tickets: | Blocking: | Differential Revisions: Phab:D660 -------------------------------------+------------------------------------- Changes (by Yuras): * status: new => merge * milestone: => 7.10.1 Comment: Already to HEAD. Austin, I just found that there will be one more RC for 7.10. In this case, it is possible to merge the patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:22:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:22:39 -0000 Subject: [GHC] #9926: Restore INSTALL file in src dist In-Reply-To: <047.2ac1500d1611590565c97bb128aecaed@haskell.org> References: <047.2ac1500d1611590565c97bb128aecaed@haskell.org> Message-ID: <062.78bebf461759447b24b905f09d55a2e2@haskell.org> #9926: Restore INSTALL file in src dist -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | 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: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"9a1c8d96f0aaf7629cdcfad5ba67aa8a1a7b9cb3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9a1c8d96f0aaf7629cdcfad5ba67aa8a1a7b9cb3" docs: add INSTALL.md to root dir (#9926) This gives a very quick rundown on installation for end-users (HACKING etc is for developers/possible contributors). Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:24:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:24:33 -0000 Subject: [GHC] #9926: Restore INSTALL file in src dist In-Reply-To: <047.2ac1500d1611590565c97bb128aecaed@haskell.org> References: <047.2ac1500d1611590565c97bb128aecaed@haskell.org> Message-ID: <062.f2e529c42f494c157d4fe48fc19a19c6@haskell.org> #9926: Restore INSTALL file in src dist -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 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: new => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via e34ca9900d5a8acf7b8da0d07989d579a718f464). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:31:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:31:07 -0000 Subject: [GHC] #10088: Broken link in Data.Ix documentation In-Reply-To: <045.c09a70d4edcadc1d6fc72f15af94ca31@haskell.org> References: <045.c09a70d4edcadc1d6fc72f15af94ca31@haskell.org> Message-ID: <060.d420ef2a3fbdbf5f48283710a249a9c9@haskell.org> #10088: Broken link in Data.Ix documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.11 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 Austin Seipp ): In [changeset:"266fa701286e1cda406e3fbae368aa9666a18980/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="266fa701286e1cda406e3fbae368aa9666a18980" base: fix broken link (#10088) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:32:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:32:00 -0000 Subject: [GHC] #10088: Broken link in Data.Ix documentation In-Reply-To: <045.c09a70d4edcadc1d6fc72f15af94ca31@haskell.org> References: <045.c09a70d4edcadc1d6fc72f15af94ca31@haskell.org> Message-ID: <060.0f35ed48c723a8629c4a9661d5b45200@haskell.org> #10088: Broken link in Data.Ix documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via 2f2b5c8b10c86c6b1495eebf229de2c18ca95f85). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:36:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:36:04 -0000 Subject: [GHC] #10091: Add configurable verbosity level to hpc executable In-Reply-To: <044.9bf53187879824adb106c81d41020873@haskell.org> References: <044.9bf53187879824adb106c81d41020873@haskell.org> Message-ID: <059.4c5e394ef26664d1a39fd56c70e0364d@haskell.org> #10091: Add configurable verbosity level to hpc executable -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | Status: closed Priority: normal | Milestone: 7.10.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: Related Tickets: | Blocking: | Differential Revisions: Phab:D660 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Done, merged via 00693e1ca9bd7c3225e1cbc377e57fb80a28d835 - thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:39:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:39:31 -0000 Subject: [GHC] #8309: traceEvent truncates to 512 bytes In-Reply-To: <045.248642a5e64e6b0cbed6adafd24ed179@haskell.org> References: <045.248642a5e64e6b0cbed6adafd24ed179@haskell.org> Message-ID: <060.7e4463494eb0d11b85bb520158ece359@haskell.org> #8309: traceEvent truncates to 512 bytes -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: eventlog Operating System: Unknown/Multiple | tracing Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #3874 | Test Case: | Blocking: | Differential Revisions: Phab:D656 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:43:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:43:38 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.cfea8243894a902ab692764e09149a02@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 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: Related Tickets: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 11:49:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 11:49:04 -0000 Subject: [GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling In-Reply-To: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> References: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> Message-ID: <059.de7d7a12f134505f3047297d0eb9f343@haskell.org> #9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D576, | Phab:D585 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * failure: None/Unknown => GHC doesn't work at all * differential: Phab:D576 => Phab:D576, Phab:D585 * component: Compiler => Compiler (LLVM) * resolution: => fixed Comment: Closing due to the patch being merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 12:36:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 12:36:32 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.005ced7d01186f109ae59d3657e2516f@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Prelude | 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 Austin Seipp ): In [changeset:"4f467b2e57ee3060d158a6505873df8c75b38c5c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4f467b2e57ee3060d158a6505873df8c75b38c5c" base: Fix (**) implementation for Data.Complex See the extensive discussion in #8539. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 12:36:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 12:36:44 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.94e0a7ada80daed9b73c98eb1e43d5a6@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Prelude | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 12:42:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 12:42:18 -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.3a4aae5aea200852214bd8a889d4cb6f@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | 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 thoughtpolice): * status: merge => new Comment: (Both commits have been merged to `ghc-7.10`, so taking out of merge state - see d67b7842548209b5d0f6bc04afab84c84adbe70c and 35a0b67dc284f8dca47089538c9ee68b06dc6f39; a discussion here may cause something to change for 7.12 in the mean time.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 12:44:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 12:44:31 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.19a7f06738bbf711a1e616d59f7c1a7e@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: patch Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a5a4c25626e11e8b4be6687a9af8cfc85a77e9ba/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a5a4c25626e11e8b4be6687a9af8cfc85a77e9ba" Provide a faster implementation for the Read Integer instance Summary: The current implementation of the Read Integer instance has quadratic complexity and thus performs badly on large inputs. This patch provides a rather simple sub-quadratic algorithm. For small inputs, we use the old algorithm (there is a small penalty for that). The gains for large inputs can be dramatic: on my system, the time to perform read (take 1000000 $ cycle "1234567890") :: Integer drops from 65 seconds to less than a second. Note that we already provide an ad-hoc instance for Show Integer, so this patch essentially does the same thing for Read Integer. Test Plan: Check that read :: String -> Integer returns correct results for inputs of various sizes. Reviewers: austin, hvr Reviewed By: austin, hvr Subscribers: ekmett, thomie Differential Revision: https://phabricator.haskell.org/D645 GHC Trac Issues: #10067 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 12:49:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 12:49:50 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.27319705af5fbd46f21aa1874b2d8f32@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => new Comment: Merged to `ghc-7.10` (via 0e0a0b4c9b2bd79f675014769e1a4777fc0e96f4). (Moving back to `new` state to continue discussion.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 13:30:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 13:30: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.25c6d1e08ef97f6d0b957614ec0be81c@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | 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: -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:14 jcpetruzza]: > Perhaps there are very good reasons to keep trace strict, but I'm not aware of them... I see 3 reasons: * For Windows gui applications, the trace message is printed to something called the debug console (if it is enabled). It prepends the message with the current time or something. I think the way it works is, we have to collect the full message first, and then make some windows api call to print the message at once. Different messages should not get interleaved, and you don't want to split a single message over multiple lines (one for each character). So on Windows we can not simply make your proposed change. It would be confusing if `trace` were only lazy in the message on other platforms, but still strict on Windows. * Debug.Trace also exports `traceEvent` and `traceMarker`, which emit a message to the GHC eventlog. Again, this is a strict operation. It would be confusing if those functions had different laziness semantics from `trace`. This could be solved with documentation. * As Edward said in comment:3, it would be a user visible change, which is better handled on the libraries list. Perhaps make a library proposal to add a new `trace` like function to Debug.Trace, that is lazy in the message? The name would be the hardest part. `traceStderr` could be an option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 14:21:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 14:21:45 -0000 Subject: [GHC] #9986: lhs -> hs fallout In-Reply-To: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> References: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> Message-ID: <063.8f684f52329979a493e59f3072264e67@haskell.org> #9986: lhs -> hs fallout -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | thoughtpolice Priority: normal | Status: closed Component: Documentation | Milestone: 7.12.1 Resolution: fixed | Version: 7.9 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: D621 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 14:23:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 14:23:17 -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.12bcaec9246e256149dfb112bc5579b4@haskell.org> #9958: System.IO.Error: Fix a documentation link to Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged via bb3b71a02483bd119cd3fd9b7c4235681b92619f, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 14:25:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 14:25:25 -0000 Subject: [GHC] #9778: Namespace collision detection for promoted types In-Reply-To: <047.2d273cde6d3a8c2e3d4c41837bafa1a1@haskell.org> References: <047.2d273cde6d3a8c2e3d4c41837bafa1a1@haskell.org> Message-ID: <062.a1656d8fdb2d647eb10f4f5cb6649ccd@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: carlostome Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: T9778 Related Tickets: | Blocking: | Differential Revisions: Phab:D534 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 14:38:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 14:38:24 -0000 Subject: [GHC] #7336: Defined but not used is not detected for data types with instances In-Reply-To: <045.ba63a779bd9def7492cb6e00f34213d2@haskell.org> References: <045.ba63a779bd9def7492cb6e00f34213d2@haskell.org> Message-ID: <060.a1d3bf132e95c92f3692d3f7662167aa@haskell.org> #7336: Defined but not used is not detected for data types with instances -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | rename/should_compile/T7336 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: cactus (added) * status: closed => new * resolution: fixed => Comment: Commit [changeset:"22ddcfff16476a6d19190f10743a78bde0b2c28f/ghc"] mentions: "T7336 is expected to be broken because of a regression introduced by pattern synonym implementation" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 14:52:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 14:52:02 -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.e47ac6003bf2a6b38f782396a4125b03@haskell.org> #17: Separate warnings for unused local and top-level bindings -------------------------------------+------------------------------------- Reporter: magunter | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: None Resolution: None | 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 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"aead01902e1c41e85b758dbafd15e60d08956374/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="aead01902e1c41e85b758dbafd15e60d08956374" driver: split -fwarn-unused-binds into 3 flags (fixes #17) Summary: New flags: -fwarn-unused-top-binds -fwarn-unused-local-binds -fwarn-unused-pattern-binds Test Plan: `tests/rename/should_compile/T17` tests Correct other tests Reviewers: austin, rwbarton Reviewed By: austin, rwbarton Subscribers: rwbarton, carter, thomie Differential Revision: https://phabricator.haskell.org/D591 GHC Trac Issues: #17 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 14:52:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 14:52:07 -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.6fec976d8baeb6ef27f067b84764a313@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 hvr): The following was suggested as regression test by Edward: {{{ >>> :set -XScopedTypeVariables -XTypeOperators -XGADTs >>> :m + Control.Lens Data.Data.Lens Data.Ratio >>> let bad = gmapT (\(x :: b) -> case eqT :: Maybe (b :~: Integer) of Nothing -> x; Just Refl -> x * 2) (1 % 2) :: Rational in bad == numerator bad % denominator bad False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 14:54:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 14:54:26 -0000 Subject: [GHC] #3055: Int / Word / IntN / WordN are unequally optimized In-Reply-To: <044.1c39597802e7cddf9bd2ebc2460d51ee@haskell.org> References: <044.1c39597802e7cddf9bd2ebc2460d51ee@haskell.org> Message-ID: <059.0755475609bfad1d4c4431e3d06da248@haskell.org> #3055: Int / Word / IntN / WordN are unequally optimized -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | simplCore/should_compile/T3055 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => simplCore/should_compile/T3055 Comment: The test has been passing for a while. Needs investigation to see if this ticket can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 15:10:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 15:10:04 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.3679bcc279536096a9bc4d42abfebdf1@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8634 | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:10 jstolarek]: > I have to ask: how did you figure that out? I don;t see anything in the error message (nor in the code) that would suggest PolyKinds are causing the problem. I was just trying to figure out what could possibly be different between the two cases. With !PolyKinds on, the empty-datatype method produces an extra degree of freedom, in the kind of the parameter to `Succ`. Seeing nothing else which could be causing difficulty, I thought !PolyKinds would have to be the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 15:16:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 15:16:48 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic In-Reply-To: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> References: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> Message-ID: <061.9e72a832ea32117561ec9e254b2ea31e@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 15:26:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 15:26:50 -0000 Subject: [GHC] #10109: Kinds aren't checked in the coverage condition Message-ID: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> #10109: Kinds aren't checked in the coverage condition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Following on from the debate in #9103 (but you don't need to read that ticket), I found a curiosity. The following module fails to compile, complaining about the unsatisfied coverage condition: {{{ {-# LANGUAGE PolyKinds, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-} module Bug where data Succ a class Add (a :: k1) (b :: k2) (ab :: k3) | a b -> ab, a ab -> b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} With `-fprint-explicit-kinds`, I get {{{ Bug.hs:9:10: Illegal instance declaration for ?Add * k * (Succ k a) b (Succ k ab)? The liberal coverage condition fails in class ?Add? for functional dependency: ?a b -> ab? Reason: lhs types ?Succ k a?, ?b? do not jointly determine rhs type ?Succ k ab? In the instance declaration for ?Add (Succ a) b (Succ ab)? }}} But, when I add `k3` to the right-hand side of the first functional dependency (viz. {{{ {-# LANGUAGE PolyKinds, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-} module Bug where data Succ a class Add (a :: k1) (b :: k2) (ab :: k3) | a b -> ab k3, a ab -> b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} ) I get {{{ [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. }}} I always assumed that fixing a type in a fundep also fixed its kind. I get the same behavior in 7.8 as in 7.10.1RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 15:38:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 15:38:45 -0000 Subject: [GHC] #10109: Kinds aren't checked in the coverage condition In-Reply-To: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> References: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> Message-ID: <062.4dd3081706ddf41dcc3665f97fec91fd@haskell.org> #10109: Kinds aren't checked in the coverage condition -------------------------------------+------------------------------------- Reporter: goldfire | 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): As a further curiosity, both versions of the program above fail without `UndecidableInstances`. How does `UndecidableInstances` affect the coverage condition check? Is this documented? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 15:40:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 15:40:45 -0000 Subject: [GHC] #9103: hackage's type-level-0.2.4 fails to compile In-Reply-To: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> References: <045.8c1a150f37f30a90e0dea42bd72ba186@haskell.org> Message-ID: <060.a917de36739c749002e1b77d1baaa1f1@haskell.org> #9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8634 | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with Janek that the coverage condition shouldn't fail there. I've opened a new ticket #10109 to explore that part, as this ticket has gotten a little muddled, and the previous discussion isn't helpful (in my opinion) in understanding #10109. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 15:43:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 15:43:10 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.38ba6535634afdd194c19bdd0e0423ea@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | simplCore/should_compile/T8832 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: thoughtpolice => * status: closed => new * resolution: fixed => Comment: `z` is still not properly constant-folded. The test is deceiving. It greps for '#', and there is no '#' in the output for `z` (not until #8274 is implemented, which I'm working on). {{{ $ ghc-7.10.0.20150123 Temp.hs -ddump-simpl -fforce-recomp -dsuppress-all -O [1 of 1] Compiling M ( Temp.hs, Temp.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 10, types: 3, coercions: 0} z2 z2 = bitInteger 0 z1 z1 = complementInteger z2 z z = andInteger z2 z1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 16:09:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 16:09:09 -0000 Subject: [GHC] #7634: MD5 collision could lead to SafeHaskell violation In-Reply-To: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> References: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> Message-ID: <061.0e281e1929805f4ce1ffa295ae4a286e@haskell.org> #7634: MD5 collision could lead to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): The move out from 7.12 was more an acknowledgement that the CLC wasn't planning on tackling this issue in 7.12. If everything is a priority then nothing is a priority, and we have lots of actionable issues with far more immediate impact. Switching fingerprints to something like SHA-256 could be done. In fact it is probably a pretty good idea, despite doubling the size of fingerprints and having a measurable performance impact -- if a patch was put forth then it would by all means be considered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 16:13:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 16:13:25 -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.a168a8ba46723e4f848bfc5158413752@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: | Blocking: | Differential Revisions: Phab:D676 -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 16:25:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 16:25:27 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed Message-ID: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.10.1-rc2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #10058 Differential Revisions: | -------------------------------------+------------------------------------- @goldfire reported in #10058 in comment 1 another failure: {{{ [43 of 55] Compiling Tests.Compile.UnitParser ( Tests/Compile/UnitParser.hs, dist/build/main/main- tmp/Tests/Compile/UnitParser.o ) : ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150123 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc6444_0/libghc6444_264.so: undefined symbol: DataziMetrologyziSIziUnits_zdfShowHectare_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} While on the surface this looks like a duplicate of #10058 it is not. The issue is only on Linux (travis to be precise), not OSX. Looking at the undefined symbol, here we see a symbol from the current module whereas in #10058 the undefined symbol lives in one of the packages. My theory is that the travis machine is running a modified link editor that defaults to `--as-needed` being set whereas the binutils default is `-no-as-needed`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 16:26:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 16:26:07 -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.7fe35944a0ac28ebac0f0d7e8b11a153@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | 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 trommler): * owner: => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 16:30:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 16:30:51 -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.92405fe36c84261b0b96ed985568a3cd@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | 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 trommler): Here is the [https://travis-ci.org/goldfirere/units/jobs/49117232 full build log] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 16:31:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 16:31:45 -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.ba6db7026bd86793dda6749f755101c0@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | 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 trommler): * component: GHCi => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 17:06:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 17:06:44 -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.8dd2c3a90b32712f31329dc18ba87048@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 ekmett): You only need {{{ >>> :m + Data.Data Data.Ratio }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 17:26:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 17:26:43 -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.09f5b6c3ddcbe53e33836a56956624bb@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 simonpj): By all means go ahead and add the test, but it'd be good to include comments that articulate what exactly it is testing! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 17:38:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 17:38:55 -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.b59cc49d72c8c5416ea10bc9dc6e75f1@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 ekmett): Basically (==) on Ratio rightfully assumes that the rational is already in lowest terms, and just compares values. {{{ >>> 2 % 4 1 % 2 }}} The test there sneaks into (1 % 2) with the old illegal Data instance and turns it into (2 :% 4), which isn't reduced, demonstrating that it is possible to produce an illegal Rational with the current instance. You could also other illegal values such as infinities, NaN-like things, negative denominators, etc. before by playing with Data.Data. All of which are ruled out by design elsewhere in the API for Rational. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 17:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 17:47:46 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.90a157ae13a6d877c53eebb2a0649953@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.11 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:D645 -------------------------------------+------------------------------------- Comment (by ekmett): For now I think option 1, which basically just merged is probably the path forward, conversion between the new Natural and Integer is quite fast. Introducing more hs-boot files, just makes more work for us going forward. We're trying, steadily, to eliminate them from base to enable a more granular system in the end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 19:27:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 19:27:08 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.1e6957a4f765ecc932b5cc548c8b0021@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | 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: #9883 | Blocking: 9883 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gershomb): * cc: gershomb@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 20:01:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 20:01:22 -0000 Subject: [GHC] #10109: Kinds aren't checked in the coverage condition In-Reply-To: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> References: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> Message-ID: <062.c038175a24a6e0dbdc9a9f3f18103f86@haskell.org> #10109: Kinds aren't checked in the coverage condition -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 20:15:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 20:15:00 -0000 Subject: [GHC] #10062: Codegen on sequential FFI calls is not very good In-Reply-To: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> References: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> Message-ID: <064.167115be21d15e62c4ecb27abc5e748c@haskell.org> #10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 20:15:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 20:15:42 -0000 Subject: [GHC] #10073: Idris REPL is pretty and we can too In-Reply-To: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> References: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> Message-ID: <063.34967782b75e0d240092afb92e78aecd@haskell.org> #10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 20:42:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 20:42:45 -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.b637576d6d9ff64b3d03992e4e3270a3@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 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => simplCore/should_compile/T8274 * differential: => Phab:D678 * type: feature request => bug * milestone: => 7.12.1 Comment: There is one small design decision to be made, and that is how to pretty print `Integer`s. Currently, unboxed `Int`s are printed as is, and `Integer`s are prepended with `__integer`. In my patch, I changed this to: unboxed `Int`s are appended with `'#'`, and `Integer`s are printed as is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 23 21:19:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Feb 2015 21:19:26 -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.d5f4e37d1b0184c10a7842fd8fec8435@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: rwbarton Type: bug | Status: patch 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 rwbarton): Yep, looks good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 01:48:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 01:48:34 -0000 Subject: [GHC] #10090: Building ghc with "make -jN" gives different base ABI hashes for N<=8 and N>8 (was: Building ghc with "make -j12" gives different ABI hashes for base to "make -j8") In-Reply-To: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> References: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> Message-ID: <065.f56846beed769b0824b04a494ce2a4f2@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: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4012 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 01:53:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 01:53:33 -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.4bafbe10acba44c183d95a28d1d9eb7a@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: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4012 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by juhpetersen): Thanks int-e for looking into this - much appreciated. :) It is encouraging indeed that this should be fixed with ghc-7.10, hopefully it won't appear again in the future. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 04:01:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 04:01:12 -0000 Subject: [GHC] #10111: hp2ps silently discards samples Message-ID: <045.6297f65476fc9401ba12c302cc0e9b8e@haskell.org> #10111: hp2ps silently discards samples -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following hp file: {{{ JOB "whatever" DATE "Sat Feb 21 12:56 2015" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.00 MAIN 1000 END_SAMPLE 0.00 BEGIN_SAMPLE 0.00 MAIN 100 END_SAMPLE 0.00 BEGIN_SAMPLE 0.01 MAIN 500 END_SAMPLE 0.01 }}} hp2ps will generate a graph showing heap usage going from 100 bytes to 500 bytes... not 1000-100-500 as expected. This is because hp2ps only uses the last sample with the same timestamp. These hp files show in practice because GHC doesn't output BEGIN_SAMPLE entries with enough precision, see also https://phabricator.haskell.org/D679 to increase the precision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 04:02:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 04:02:11 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.f7e22e70d9503e4003c2955923cc15e3@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:9 simonpj]: > 2. Only one field with nonzero width in that constructor (counting constraints as fields) I'd like to point out (as may already have been indented), that read literally, this should include things like {{{ data Dict :: Constraint -> * where Dict :: a => Dict a }}} from the `constraints` package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 04:02:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 04:02:44 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.1b4bb369e5609a4af7eede4443fbd478@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | 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 oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 09:13:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 09:13:27 -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.e10fdb2e735aae7e712aa5fb9a2be6a7@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: patch Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc1 (other) | Keywords: Resolution: | Architecture: sparc Operating System: Solaris | Test Case: Type of failure: Building GHC | Blocking: failed | Differential Revisions: Phab:D675 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"5be8ed4da1963ed2d45a65fb61d761c977707cce/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5be8ed4da1963ed2d45a65fb61d761c977707cce" Emulate GMP 5+ operations for GMP 4.x compat The following operations are only (officially) available starting with GMP 5.0: - `mpn_and_n` - `mpn_andn_n` - `mpn_ior_n` - `mpn_xor_n` In order to properly support GMP 4.x, we simply emulate those operation in terms of `mpz_*` operations available in GMP 4.x (unless GMP>=5.x available, obviously) while incurring some overhead. Ideally, GMP 4.x environments will reach their EOL in the foreseeable future... This fixes #10003 Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D675 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 09:28:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 09:28:27 -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.68914ca1d0c221a3cba5b94039b82032@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: merge Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc1 (other) | Keywords: Resolution: | Architecture: sparc Operating System: Solaris | Test Case: Type of failure: Building GHC | Blocking: failed | Differential Revisions: Phab:D675 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 12:37:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 12:37:56 -0000 Subject: [GHC] #10112: Desugaring of do-syntax intros unification var with -XRebindableSyntax Message-ID: <048.4d43585c73cf5632373b4b1e6f28bd29@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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When compiling below snippet with GHC 7.8.x (and I believe v7.10.x) {{{ {-# LANGUAGE RankNTypes, RebindableSyntax #-} import qualified Prelude as P (>>=) :: a -> ((forall b . b) -> c) -> c a >>= f = f P.undefined return a = a fail s = P.undefined t1 = 'd' >>= (\_ -> 'k') t2 = do _ <- 'd' 'k' main = P.putStrLn [t1, t2] }}} we get this error: {{{ Ztest.hs:12:9: Cannot instantiate unification variable `t0` with a type involving foralls: forall b. b Perhaps you want ImpredicativeTypes In a stmt of a 'do' block: _ <- 'd' In the expression: do { _ <- 'd'; 'k' } In an equation for `t2`: t2 = do { _ <- 'd'; 'k' } Failed, modules loaded: none. }}} In GHC HEAD (and v7.6.x) the error does not appear. Nevertheless I'll file this bug for addition of a regression test. Discussion here: https://mail.haskell.org/pipermail/ghc- devs/2015-February/008383.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 14:41:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 14:41:21 -0000 Subject: [GHC] #7634: MD5 collision could lead to SafeHaskell violation In-Reply-To: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> References: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> Message-ID: <061.6f9ae1dc2103ec3600ea2300ad556f2a@haskell.org> #7634: MD5 collision could lead to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bananu7): A quick investigation shows that there are two parts of the problem: * `Fingerprint` is made of two `Word64`s; would need to change to four, and all the functions that manipulate on it to take four parts into account; that's an easy part * MD5 implementation used internally for hashing is written in C. I suppose the SHA-256 implementation that's necessary for the patch ''could'' be taken from `cryptohash` library, which seems pretty mature already. It would need to be integrated as a C source similarly to MD5; It's probably not feasible to drag the whole library as a GHC dependency; maybe I'm wrong here. Then the functions that have to be altered are `fingerprintData` and `fingerprintString`, the latter needing just to take the larger size of the fingerprint into the account, and the former actually being changed to use the SHA-256 context and hashing function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 15:28:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 15:28:24 -0000 Subject: [GHC] #7634: MD5 collision could lead to SafeHaskell violation In-Reply-To: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> References: <046.34cd876647777e2f664ed7cf8a69ba93@haskell.org> Message-ID: <061.92863894ee68652743813364db28a13b@haskell.org> #7634: MD5 collision could lead to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Pretty much. There are also dozens if not hundreds of SHA-256 implementations out there in C we could take in more or less unmodified. Heck, I've even written one before, back in my crypto days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 15:44:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 15:44:20 -0000 Subject: [GHC] #8189: Default to infinite stack size? In-Reply-To: <042.d9fd9c0b598b6d47230205c66ae56e03@haskell.org> References: <042.d9fd9c0b598b6d47230205c66ae56e03@haskell.org> Message-ID: <057.bf882fd9b9d3edd36eb0533e0151e4c0@haskell.org> #8189: Default to infinite stack size? -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 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 ekmett): If having an unbounded stack size was the default behavior the last reason that `mapM` has to live would go away. This would let us dramatically simplify `Traversable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 15:52:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 15:52:40 -0000 Subject: [GHC] #10113: Re-export (<$>) from Prelude Message-ID: <042.94e62203b187cd4423f8632566f19490@haskell.org> #10113: Re-export (<$>) from Prelude -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: highest | Version: 7.10.1-rc2 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: AMP | Blocked By: Architecture: | Related Tickets: #4834 Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: Phab:D680 | -------------------------------------+------------------------------------- See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 15:53:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 15:53:35 -0000 Subject: [GHC] #10113: Re-export (<$>) from Prelude In-Reply-To: <042.94e62203b187cd4423f8632566f19490@haskell.org> References: <042.94e62203b187cd4423f8632566f19490@haskell.org> Message-ID: <057.f43e85141a6ab8b02f311dbd3406dcfd@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 -------------------------------------+------------------------------------- Changes (by hvr): * keywords: AMP => AMP report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 16:51:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 16:51:18 -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.7ba07ac3fe29a66bf05c9ebbb8af1f7a@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): My apologies if I am off base, but I think I have an example. I'm making a visualization server that handles the rendering of 3d* graphics. The server listens for messages regarding "entity" primitives and current point of view. For every entity it adds it handshakes to the client with a unique id, so that the client can update the entity if needed. The basic service deals with primitive shapes, and the idea is to develop client services which can translate between higher level abstractions and the visualization primitives. For example, a plotting utility might be a client which exposes an "axes" primitive, which in turn relates to a set of visualization primitives used for tic marks, axis lines, and labels. I'm organizing the architecture to be based on the below Client and Server type classes. Clients create commands and further processing based on the responses to the commands. Servers listen to commands, do something, and eventually return responses. The classes attempt to separate out the key protocol/visualization components from the actual implementation. The forwarding action below pastes together clients and servers, and will hopefully be reusable for making concrete services based on different messaging technologies, and for implementations for different visualization domains. It seems to require AmbiguousTypes, though I don't understand why. {{{#!haskell {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE AllowAmbiguousTypes #-} module CSFwd where import VisServ.Base import Data.Monoid (mconcat,Monoid) -- | Imported from VisServ.Base --type family ComResp cmd -- |triggered by some data, trig, a client request yields a list of commands, cmd, -- and functions which consume the resulting response. class ClientAction cmd trig a where clientRequest :: trig -> [(cmd, ComResp cmd -> a)] -- |triggered by some command, cmd, a server does some reaction, react, and -- given subsequent data, a, (presumably somehow derived from react) will -- respond to the command, ComResp cmd. class ServerAction cmd react a where serverResponse :: cmd -> (react, a -> ComResp cmd) -- The idea with forwarding action hinges to a large part around the server response -- (a->c->d). The idea being that whatever implementation of this server will have -- some data, a, available which needs to be combined with, c, to yield data, d, -- necessary for a response to the original metaCmd request. The data, c, can be -- created based on replys to visualization commands So, given the input functions -- which create the client trigger and initial data b, this function handles the -- forwarding of visualization commands based on some other commands. forwardingAction :: forall a b c d trig metaCmd . ( Monoid c , ServerAction metaCmd (a->c->d) d , ClientAction VisCom trig (b->c) ) => (metaCmd -> a -> trig) -> (metaCmd -> b) -> metaCmd -> a -> ([VisCom],[VisResp] -> d, d -> ComResp metaCmd) forwardingAction toTrig tob metaCmd a = (cliCmds,servReact',cmdResp) where (servReact::(a->c->d),cmdResp::d -> ComResp metaCmd) = serverResponse metaCmd cmdActs :: [(VisCom,VisResp -> b -> c)] cmdActs = clientRequest . toTrig metaCmd $ a (cliCmds,replResps) = unzip cmdActs b = tob metaCmd replResp' :: [VisResp] -> c replResp' resps = mconcat $ zipWith (\f resp-> f resp b) replResps resps servReact' :: [VisResp] -> d servReact' resps = servReact a (replResp' resps) }}} Error: {{{ src/CSFwd.hs:33:21: Could not deduce (ClientAction VisCom trig (b -> c0)) arising from the ambiguity check for ?forwardingAction? from the context (Monoid c, ServerAction metaCmd (a -> c -> d) d, ClientAction VisCom trig (b -> c)) bound by the type signature for forwardingAction :: (Monoid c, ServerAction metaCmd (a -> c -> d) d, ClientAction VisCom trig (b -> c)) => (metaCmd -> a -> trig) -> (metaCmd -> b) -> metaCmd -> a -> ([VisCom], [VisResp] -> d, d -> ComResp metaCmd) at src/CSFwd.hs:(33,21)-(38,67) The type variable ?c0? is ambiguous In the ambiguity check for: forall a b c d trig metaCmd. (Monoid c, ServerAction metaCmd (a -> c -> d) d, ClientAction VisCom trig (b -> c)) => (metaCmd -> a -> trig) -> (metaCmd -> b) -> metaCmd -> a -> ([VisCom], [VisResp] -> d, d -> ComResp metaCmd) To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?forwardingAction?: forwardingAction :: forall a b c d trig metaCmd. (Monoid c, ServerAction metaCmd (a -> c -> d) d, ClientAction VisCom trig (b -> c)) => (metaCmd -> a -> trig) -> (metaCmd -> b) -> metaCmd -> a -> ([VisCom], [VisResp] -> d, d -> ComResp metaCmd) }}} *Technically not real 3D. I'm using some projective transforms to create 2D vector graphics based on the diagrams front end. I use a simple ordering over the transformed shapes to determine the order they are glued to the page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 18:33:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 18:33:44 -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.dcfa47c0682b79b174841ee56f54d94e@haskell.org> #10001: GHC crash trying to build a project within Nix-shell -------------------------------------+------------------------------------- Reporter: wolftune | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- Comment (by teh): I have a reproducible example: https://gist.github.com/teh/d94a704254c834af6cdf I get {{{ [...] Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. : ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1000/ghc1352_0/ghc1352_3.so: failed to map segment from shared object }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 21:16:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 21:16:17 -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.a6c5f20b913066256471dd644774a890@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: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) Comment: The section 'Views of types' in [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TypeType this wiki page] is outdated as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 22:37:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 22:37:01 -0000 Subject: [GHC] #8189: Default to infinite stack size? In-Reply-To: <042.d9fd9c0b598b6d47230205c66ae56e03@haskell.org> References: <042.d9fd9c0b598b6d47230205c66ae56e03@haskell.org> Message-ID: <057.ea81e4bab0fa27da7e63223ada9da9ad@haskell.org> #8189: Default to infinite stack size? -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 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 carter): @ekmett, unbounded stack size (up to whatever limits the heap provides, or maybe 80% of the heap limit) IS the default now as of 7.8 onwards as far as I know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 22:46:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 22:46:13 -0000 Subject: [GHC] #10114: Kind mismatches with AnyK in rank-2 types Message-ID: <042.b276c0a2c2e93f214c57d6cb2cc81838@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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following module: {{{#!hs {-# LANGUAGE Rank2Types #-} module KindBug where type T = forall f a. f a foo :: T foo = undefined bar :: forall f a. f a bar = foo }}} ...produces the following error: {{{ [1 of 1] Compiling KindBug ( KindBug.hs, KindBug.o ) KindBug.hs:10:7: Kind incompatibility when matching types: f0 :: AnyK -> * f :: * -> * Expected type: f a Actual type: f0 a0 Relevant bindings include bar :: f a (bound at KindBug.hs:10:1) In the expression: foo In an equation for ?bar?: bar = foo }}} Note that no extensions are enabled other than rank-2 types. Enabling and using kind annotations fixes the error, as does replacing the type synonym with its definition in the type signature of foo. Similar errors can also be generated with PolyKinds enabled and less plausible code, e.g. {{{ (return undefined :: forall f a. f a) :: f a }}}. The non-PolyKinds example is simplified from some actual code, where the type synonym was similar to the ones used in lens, and is the simplest example I could find (with help from Shachaf on IRC) that resembled real code. I searched for existing tickets and the closest I could find are #7916 and #5935, both of which are already fixed. Also, according to glguy (Eric Mertens) just now in #haskell-lens, the same error occurs in the 7.10 branch and in 7.11.20150120. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 22:53:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 22:53:18 -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.abc14427a6397774cd78769e5d426a32@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 George): Workaround is to use llvm 3.5 correct? If so, should the priority be high? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 22:59:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 22:59:03 -0000 Subject: [GHC] #9868: ghc: panic! Dynamic linker not initialised In-Reply-To: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> References: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> Message-ID: <061.4762eb19eb9ac563515a0a9a62307236@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 mpickering): I'm also experiencing this trying to build hackage-server. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 24 23:20:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Feb 2015 23:20:45 -0000 Subject: [GHC] #4861: Documentation for base does not include special items In-Reply-To: <051.5ee4c1527610ef4964c665e655014652@haskell.org> References: <051.5ee4c1527610ef4964c665e655014652@haskell.org> Message-ID: <066.67dc07c09a63ce97c8c496f6eaca0577@haskell.org> #4861: Documentation for base does not include special items -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: ekmett Type: bug | Status: upstream Priority: low | Milestone: ? Component: Core Libraries | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * milestone: 7.12.1 => ? Comment: Deferring to _|_ as there doesn't appear to be any great desire on the part of the `haddock` folks to change this behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 25 08:23:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Feb 2015 08:23:12 -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.3e8318a0f407ddc82f6af1f55026f682@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 jstolarek): I believe GHC is right to reject this program. Look at the type signature of `forwardingAction`: {{{#!hs forwardingAction :: forall a b c d trig metaCmd . ( Monoid c , ServerAction metaCmd (a->c->d) d , ClientAction VisCom trig (b->c) ) => (metaCmd -> a -> trig) -> (metaCmd -> b) -> metaCmd -> a -> ([VisCom],[VisResp] -> d, d -> ComResp metaCmd) }}} Note that the `c` type variable - the on GHC claims is ambiguous - appears only under type classes in the context. It does not appear in type of any argument nor the return type. This means that at the call site there might be no way to infer what type should the `c` variable be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 25 09:37:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Feb 2015 09:37:01 -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.8d5c16e15efeea0e75ae105a0027d2d9@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 -------------------------------------+------------------------------------- Changes (by trommler): * related: => #10110 Comment: Replying to [comment:14 goldfire]: > Ah -- I understand just enough of that to see why you want a new ticket. Done: #10110 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 25 10:25:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Feb 2015 10:25:44 -0000 Subject: [GHC] #10115: Unable to run cabal haddock --hoogle on GHC 7.10 Message-ID: <047.decd164805e4d10458a8e3160e406e34@haskell.org> #10115: Unable to run cabal haddock --hoogle on GHC 7.10 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At Herbert's recommendation, creating an issue based on the following email I sent to ghc-dev: I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not work. There seem to be two different issues open about it: https://github.com/haskell/haddock/issues/361 https://github.com/haskell/cabal/issues/2297 I really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 25 10:26:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Feb 2015 10:26:32 -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.4571bce34228215e92ac2dc90fe9d039@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: -------------------------------------+------------------------------------- Changes (by snoyberg): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 25 20:45:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Feb 2015 20:45:03 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases Message-ID: <049.356115fff338ba416dd9590b8ce78129@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: 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: | -------------------------------------+------------------------------------- Right now, I can do the following: data Foo = A | B type family Bar (n :: 'Foo) where Bar 'A = Int I would like to be warned if I write a partial type function like this because partial functions are almost always a mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 25 20:58:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Feb 2015 20:58:02 -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.1ceb84f7d9c4921e6631583bc085a5bd@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: new 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: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * component: Compiler => Compiler (Type checker) * milestone: => 7.12.1 Comment: More bugs. GHC only rejects the following program when `-XConstrainedClassMethods` is turned on. It should however always reject it, because `op` doesn't mention any type variables of `Foo`. {{{#!hs module ShouldFail where class Foo a where op :: Eq a => Int }}} I'm working on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 01:55:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 01:55:26 -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.b3aba312664fd741ad98c31df1986609@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): Same for 7.8.4 btw ;) Downstream bug is https://bugzilla.redhat.com/show_bug.cgi?id=1195231 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 08:37:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 08:37:50 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.d67d934777fac81077aeee3ddf904b9d@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | 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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) * type: task => feature request Old description: > Right now, I can do the following: > > data Foo = A | B > type family Bar (n :: 'Foo) where > Bar 'A = Int > > I would like to be warned if I write a partial type function like this > because partial functions are almost always a mistake. New description: Right now, I can do the following: {{{#!hs data Foo = A | B type family Bar (n :: 'Foo) where Bar 'A = Int }}} I would like to be warned if I write a partial type function like this because partial functions are almost always a mistake. -- Comment: Checking pattern exhaustiveness for closed type families could also allow us to detect unreachable equations: {{{#!hs data Foo = A | B type family Bar (n :: Foo) where Bar 'A = Int Bar 'B = Char Bar a = Double }}} Here the last equation is unreachable but GHC does not discover this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 10:25:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 10:25:12 -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.62b8adce3ccd2541edbcfd47f2fa0496@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): Some notes for myself (work in progress). At the moment, for type `T` above we get {{{ -- Without PolyKinds type T = forall (f :: AnyK -> *) (a :: AnyK). f a -- With PolyKinds type T k = forall (f :: AnyK -> k) (a :: AnyK). f a }}} Trouble is that we are not generalising over the kind of `a`. I think we want: {{{ -- Without PolyKinds type T = forall (f :: * -> *) (a :: *). f a -- With PolyKinds type T k1 k2 = forall (f :: k1 -> k2) (a :: k1). f a }}} But note the strange kind of `T` in `PolyKinds` case: `T :: forall k1 k2. k2`. I'm pretty sure we do NOT want to kind-generalise "inside", thus: {{{ type T = forall k1 k2 (f :: k1->k2) (a::k1). f a }}} Reasons: * see `Note [Kind generalisation]` in `TcHsType` * what kind would `T` have? `T :: k2` ??? * more operationally, kind foralls must be implicitly instantiated, during kind inference using only `T`'s kind -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 15:30:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 15:30:20 -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.a1aedfa0d970eb3ae571c5a9ce69774c@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): What about {{{ type T k2 = forall k1 (f :: k1 -> k2) (a :: k1). f a }}} That makes `T :: forall k2. k2`. That's a well-formed kind, but it looks awfully like the type of `undefined`... but I don't know if that's a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 15:38:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 15:38:13 -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.16424ac9bfe194f75bd75ae57588fa5a@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): Re comment:2, I don't think so: how does `k1` get instantiated when you have occurrences of `T`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 16:04:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 16:04:10 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.360a4b1f72be7ca65f4774cb471f5c2e@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | 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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: george.karachalias@?, tom.schrijvers@? (added) Comment: George Karachalias and Tom Schrijvers are busy building a cool new pattern-match checker for GHC. We have an ICFP submission nearly finished; I'll put it up in a day or three. Once it's in, it could probably be adapted to do type families too, but it'd be a bit of work. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 16:10:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 16:10:12 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.195f50daf65b980ab459ef4e26ea6975@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | 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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I conjecture that getting this completely right for closed type families is a research project of its own, because closed type families allow for repeated variables. For example: {{{ type family F (a :: Bool) (b :: Maybe Bool) :: Nat where F True (Just False) = 0 F False (Just True) = 1 F x (Just x) = 2 F y Nothing = 3 }}} Is that total? I do believe it is. But it's a little hard to figure it out! But we could certainly do ''something'' in this area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 16:51:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 16:51:28 -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.0d81ae832397ae86cb95bfbc96f829f2@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: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rebundable/T10112 Comment: I'll do that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 17:03:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 17:03:02 -0000 Subject: [GHC] #10117: Change the scheme for reporting redundant imports Message-ID: <046.c9fe94ada7957e35dfd23f2313543a1b@haskell.org> #10117: Change the scheme for reporting redundant imports -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- The current scheme for reporting redundant imports is given on the [wiki:Commentary/Compiler/UnusedImports unused imports page]. [wiki:Migration/7.10#GHCsaysTheimportof...isredundant The 7.10 migration page] describes a hack to avoid redundant-import warnings during migration, without using CPP. The hack works for {{{ module Foo (Int, Word, Monoid(..)) where import Data.Monoid import Data.Word import Prelude }}} (the hack is putting `import Prelude` at the bottom). To understand why, read the specification on the [wiki:Commentary/Compiler/UnusedImports unused imports page]. But it fails for {{{ module Foo (Int, Word, Monoid(..)) where import Data.Monoid (Monoid(..)) import Data.Word (Word) import Prelude }}} because the specification treats itemised imports like `import Data.Word(Word)` differently to "import all" imports. The question: '''is there alternative spec (vs the one on the [wiki:Commentary/Compiler/UnusedImports unused imports page]) that would support the behaviour desired here, without having other undesirable consequences?''' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 17:26:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 17:26:53 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic In-Reply-To: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> References: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> Message-ID: <061.89f761a846b88931a44f67875de20004@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | 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 simonpj): I'd appreciate guidance from the Core Libraries Committee here. I plan to execute the above changes for 7.12, but it'll clearly be a bit disruptive for people `Typeable`, `Data` etc. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 17:54:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 17:54:42 -0000 Subject: [GHC] #10118: No ambiguity check when `ConstrainedClassMethods` is on Message-ID: <045.5132acf01a91a22dd01f11d8230744c0@haskell.org> #10118: No ambiguity check when `ConstrainedClassMethods` is on -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #7854 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program is wrongfully accepted when `ConstrainedClassMethods` is on: {{{#!hs module ShouldFail where class Foo a where op :: Eq b => a -> Int }}} I have a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 19:06:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 19:06:08 -0000 Subject: [GHC] #10119: Class methods must always mention the class variable Message-ID: <045.c4e7c6552a1c88ca34b36be1aea67501@haskell.org> #10119: Class methods must always mention the class variable -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #7854, #10118 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As mentioned in comment:9:ticket:7854, GHC wrongfully accepts the following program. It should reject it, because `op` doesn't mention any type variables of `Foo` (the method context doesn't count). {{{#!hs module ShouldFail where class Foo a where op :: Eq a => Int }}} I'm working on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 20:51:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 20:51:58 -0000 Subject: [GHC] #4316: Interactive "do" notation in GHCi In-Reply-To: <044.bcb097c9c29d1eda57c965914e3510cd@haskell.org> References: <044.bcb097c9c29d1eda57c965914e3510cd@haskell.org> Message-ID: <059.d2af2ce867c9f1edd810938f7916a909@haskell.org> #4316: Interactive "do" notation in GHCi -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 4459 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by yokto): * cc: yokto (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 22:42:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 22:42:27 -0000 Subject: [GHC] #4372: Extending quasiquotation support In-Reply-To: <046.070081740d53fd2b18d950319658559f@haskell.org> References: <046.070081740d53fd2b18d950319658559f@haskell.org> Message-ID: <061.a9a13acc577d2752ca63dc6eb35d3a8e@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 simonpj): I'm not against this if someone wants to * Write a wiki page explaining the feature * Drive a discussion to refine any corners of the design; it's mainly a syntax question I think. * Implement a patch on Phabricator; including user manual documentation and some tests. > Another problem is that I suppose that the 4 quoters t, p, e, d are implemented in the layer of syntax I'm afraid I did not understand this part of your comment. Maybe it's a separate issue? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 22:44:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 22:44:56 -0000 Subject: [GHC] #4960: Better inlining test in CoreUnfold In-Reply-To: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> References: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> Message-ID: <061.3b4636885ec72cd6f1bc4d80c46cabc4@haskell.org> #4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 22:49:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 22:49:28 -0000 Subject: [GHC] #10106: GHC doesn't warn on typos in language pragmas In-Reply-To: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> References: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> Message-ID: <060.5998755714bdc900f9925f0dc41f3f2e@haskell.org> #10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #10076 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The underlying issue here is: * A "warning" differs from an "error", in that only the latter halt compilation (unless you use `-Werror`. * We do not display warnings if there are any errors, to draw attention to the errors. Maybe we need some kind of in-between thing, say a "prominent warning". It is like a warning in that it does not halt compilation. But it is not suppressed by errors. Then a mis-spelled pragma could be a "prominent warning". Bizarrely, we currently have no fewer than '''seven''' levels of severity for output messages: {{{ data Severity = SevOutput | SevDump | SevInteractive | SevInfo | SevWarning | SevError | SevFatal }}} (in `Error.hs`). The intended semantics of these levels is entirely undocumented, and I have no clue what they mean. I would love this to documented; probably we can nuke several levels. But adding `SevProminentWarning` (properly documented) would arguably do little harm. But someone would have to want to do it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 22:51:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 22:51: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.ca6a0a750210f4ea2d2893b3f67b3347@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 simonpj): > I may have found a way to reliably reproduce this bug using real code: Well you are reliably producing ''some'' bug, but I think it's pretty unlikely that it is the subject of this ticket! Does it happen with the 7.10 release candidate? Have you got `-dcore-lint` on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 23:01:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 23:01:11 -0000 Subject: [GHC] #4372: Extending quasiquotation support In-Reply-To: <046.070081740d53fd2b18d950319658559f@haskell.org> References: <046.070081740d53fd2b18d950319658559f@haskell.org> Message-ID: <061.01d0b9e70dfbdcb524090872264278dc@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 gershomb): At this point I consider this a "nice idea" but I'm not sure how to modify the parser to handle it within the many grammatical constraints we already have. The somewhat clunky syntax that was pointed out by Simon upthread is actually adequate for this. This, for example is the style adopted by Manuel's language-c-inline: {{{ nslog msg = $(objc ['msg :> ''String] (void [cexp| NSLog(@"Here is a message from Haskell: %@", msg) |])) }}} Here, we use the quasiquoter to capture the expression, and then embed that quasiquoted expression itself within a TH block, in order to pass in additional information during codegen. If a lighter-weight syntax was possible, I'd remain all for it. But, I honestly can't think how to provide it given the constraints we have -- my patch at the time didn't really solve the problem, and I haven't had any better ideas since :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 26 23:25:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Feb 2015 23:25:45 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.7c3696bd70bd42effe349c4a14ca60cf@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: -------------------------------------+------------------------------------- Changes (by gershomb): * cc: gershomb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 00:06:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 00:06:05 -0000 Subject: [GHC] #10026: wiki formatting doc does not mention language option In-Reply-To: <048.ac2aa181d221a581209e7b02b7b58bf4@haskell.org> References: <048.ac2aa181d221a581209e7b02b7b58bf4@haskell.org> Message-ID: <063.69f70174204f011de17d061f64c6d011@haskell.org> #10026: wiki formatting doc does not mention language option -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | 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 bgamari): It would be nice to mention this somewhere; I can never remember this incantation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 00:40:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 00:40:32 -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.7abffab94ab374b683ac6e4bad4a9368@haskell.org> #10118: No ambiguity check when `ConstrainedClassMethods` is on -------------------------------------+------------------------------------- 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/T10118 Related Tickets: #7854 | Blocking: | Differential Revisions: Phab:D686 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => typecheck/should_fail/T10118 * differential: => Phab:D686 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 00:44:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 00:44:31 -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.ea698dd2b983ef3f7c2ea984110213a9@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: D687 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => typecheck/should_fail/T10119 * differential: => D687 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 01:13:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 01:13: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.b857a27070b70258d50e546b6b827ebd@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 -------------------------------------+------------------------------------- Changes (by thomie): * differential: D687 => Phab:D687 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 01:17:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 01:17:31 -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.a4a7b115cde31857a8442737a8f7e00b@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 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => typechecker/should_fail/T7854 * differential: => Phab:D688 * related: => #10118, #10119 Comment: Patches are ready for review in Phab:D686, Phab:D687 and Phab:D688. Instead of deprecating `ConstrainedClassMethods`, I have tried fixing it instead. Phab:D688 turns on `ConstrainedClassMethods` for all modes (Haskell98, Haskell2010 and default), to not break any programs. I added a section to "Known bugs and infelicities". Existing tests `tcfail149` and `tcfail150` have been reenabled, and I added `T7854` for the `MultiParamTypeClasses` case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 01:22:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 01:22:18 -0000 Subject: [GHC] #10026: wiki formatting doc does not mention language option In-Reply-To: <048.ac2aa181d221a581209e7b02b7b58bf4@haskell.org> References: <048.ac2aa181d221a581209e7b02b7b58bf4@haskell.org> Message-ID: <063.c29921b37f8a5c69653ed5536c9c2b9e@haskell.org> #10026: wiki formatting doc does not mention language option -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | 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 thomie): Does this help: https://ghc.haskell.org/trac/ghc/wiki/WikiFormatting?action=edit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 03:27:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 03:27:29 -0000 Subject: [GHC] #4372: Extending quasiquotation support In-Reply-To: <046.070081740d53fd2b18d950319658559f@haskell.org> References: <046.070081740d53fd2b18d950319658559f@haskell.org> Message-ID: <061.6249783538fcaeb0a63cdeed5de2b6bc@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 songzh): Replying to [comment:19 gershomb]: > At this point I consider this a "nice idea" but I'm not sure how to modify the parser to handle it within the many grammatical constraints we already have. The somewhat clunky syntax that was pointed out by Simon upthread is actually adequate for this. This, for example is the style adopted by Manuel's language-c-inline: > I am sorry for not being a GHC developer, I will try to be one. I have skimmed the parser in the source code. My understanding is that the quoters do not need to be all kinds of expressions since allowing only function application will be more than enough. If expression like CondE, MultiIfE, DoE, CompE should be not allowed in quoter position, the guarded expression and other syntax problem will vanish. For achieving this, maybe a specific parser for quoter position is needed. I am just blind guessing here. > {{{ > nslog msg = $(objc ['msg :> ''String] (void [cexp| NSLog(@"Here is a message from Haskell: %@", msg) |])) > }}} > > Here, we use the quasiquoter to capture the expression, and then embed that quasiquoted expression itself within a TH block, in order to pass in additional information during codegen. > > If a lighter-weight syntax was possible, I'd remain all for it. But, I honestly can't think how to provide it given the constraints we have -- my patch at the time didn't really solve the problem, and I haven't had any better ideas since :-) I will look into the c-language package and your patch. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 03:43:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 03:43:12 -0000 Subject: [GHC] #4372: Extending quasiquotation support In-Reply-To: <046.070081740d53fd2b18d950319658559f@haskell.org> References: <046.070081740d53fd2b18d950319658559f@haskell.org> Message-ID: <061.899b3805b442f0cf11a389f7be985892@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 songzh): Replying to [comment:18 simonpj]: > I'm not against this if someone wants to > * Write a wiki page explaining the feature > * Drive a discussion to refine any corners of the design; it's mainly a syntax question I think. > * Implement a patch on Phabricator; including user manual documentation and some tests. > > > Another problem is that I suppose that the 4 quoters t, p, e, d are implemented in the layer of syntax > > I'm afraid I did not understand this part of your comment. Maybe it's a separate issue? > Simon It is not an issue, only a design decision. I was excepting {{{ > :t e e :: QuasiQuoter }}} but it is actually syntax. A little bit surprised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 05:30:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 05:30:31 -0000 Subject: [GHC] #10120: Unnecessary code duplication from case analysis Message-ID: <046.10c61b673d034de53b4da023888f711a@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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider a case analysis like this, {{{#!hs predicate c = c == '-' || c == '_' || c == '.' || c == '~' || c == ':' || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == ',' f x | predicate x = do_something f x = do_something_else main = f 'a' }}} GHC in some cases appears to produce Core for this example by constructing a case analysis on `x`, replicating `do_something` in every branch, {{{#!hs $wa_r3UQ :: GHC.Prim.Char# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GblId, Arity=2, Str=DmdType ] $wa_r3UQ = \ (ww_s3TD :: GHC.Prim.Char#) (w_s3TA [OS=OneShot] :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ww_s3TD of _ [Occ=Dead] { __DEFAULT -> (# w_s3TA, GHC.Tuple.() #); '$' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl2_r3Uv GHC.Types.True w_s3TA; '&' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl4_r3Ux GHC.Types.True w_s3TA; '+' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl6_r3Uz GHC.Types.True w_s3TA; ',' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl8_r3UB GHC.Types.True w_s3TA; '-' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl10_r3UD GHC.Types.True w_s3TA; '.' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl12_r3UF GHC.Types.True w_s3TA; ':' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl14_r3UH GHC.Types.True w_s3TA; '=' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl16_r3UJ GHC.Types.True w_s3TA; '@' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl18_r3UL GHC.Types.True w_s3TA; '_' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl20_r3UN GHC.Types.True w_s3TA; '~' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl22_r3UP GHC.Types.True w_s3TA } }}} This seems to be sub-optimal for instruction cache efficiency, the number of branches in generated machine code, code size, and understandability of the resulting Core. I would have expected something like, ```#!hs f x = let p = pred x in case p of True -> do_something False -> do_something_else ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 05:31:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 05:31:15 -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.9f1738e15236a0d38f085c67d328ca10@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: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Consider a case analysis like this, > > {{{#!hs > predicate c = > c == '-' || c == '_' || c == '.' || c == '~' || c == ':' > || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == > ',' > > f x | predicate x = do_something > f x = do_something_else > main = f 'a' > }}} > > GHC in some cases appears to produce Core for this example by > constructing a case analysis on `x`, replicating `do_something` in every > branch, > > {{{#!hs > $wa_r3UQ > :: GHC.Prim.Char# > -> GHC.Prim.State# GHC.Prim.RealWorld > -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) > [GblId, Arity=2, Str=DmdType ] > $wa_r3UQ = > \ (ww_s3TD :: GHC.Prim.Char#) > (w_s3TA [OS=OneShot] :: GHC.Prim.State# GHC.Prim.RealWorld) -> > case ww_s3TD of _ [Occ=Dead] { > __DEFAULT -> (# w_s3TA, GHC.Tuple.() #); > '$' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl2_r3Uv GHC.Types.True w_s3TA; > '&' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl4_r3Ux GHC.Types.True w_s3TA; > '+' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl6_r3Uz GHC.Types.True w_s3TA; > ',' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl8_r3UB GHC.Types.True w_s3TA; > '-' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl10_r3UD GHC.Types.True w_s3TA; > '.' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl12_r3UF GHC.Types.True w_s3TA; > ':' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl14_r3UH GHC.Types.True w_s3TA; > '=' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl16_r3UJ GHC.Types.True w_s3TA; > '@' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl18_r3UL GHC.Types.True w_s3TA; > '_' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl20_r3UN GHC.Types.True w_s3TA; > '~' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl22_r3UP GHC.Types.True w_s3TA > } > }}} > > This seems to be sub-optimal for instruction cache efficiency, the number > of branches in generated machine code, code size, and understandability > of the resulting Core. I would have expected something like, > > ```#!hs > f x = > let p = pred x > in case p of > True -> do_something > False -> do_something_else > ``` New description: Consider a case analysis like this, {{{#!hs predicate c = c == '-' || c == '_' || c == '.' || c == '~' || c == ':' || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == ',' f x | predicate x = do_something f x = do_something_else main = f 'a' }}} GHC in some cases appears to produce Core for this example by constructing a case analysis on `x`, replicating `do_something` in every branch, {{{#!hs $wa_r3UQ :: GHC.Prim.Char# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GblId, Arity=2, Str=DmdType ] $wa_r3UQ = \ (ww_s3TD :: GHC.Prim.Char#) (w_s3TA [OS=OneShot] :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ww_s3TD of _ [Occ=Dead] { __DEFAULT -> (# w_s3TA, GHC.Tuple.() #); '$' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl2_r3Uv GHC.Types.True w_s3TA; ... '_' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl20_r3UN GHC.Types.True w_s3TA; '~' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl22_r3UP GHC.Types.True w_s3TA } }}} This seems to be sub-optimal for instruction cache efficiency, the number of branches in generated machine code, code size, and understandability of the resulting Core. I would have expected something like, {{{#!hs f x = let p = pred x in case p of True -> do_something False -> do_something_else }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 05:32:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 05:32:10 -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.b29a1135229d1b35f7f1c6f49d0c1d99@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: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Consider a case analysis like this, > > {{{#!hs > predicate c = > c == '-' || c == '_' || c == '.' || c == '~' || c == ':' > || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == > ',' > > f x | predicate x = do_something > f x = do_something_else > main = f 'a' > }}} > > GHC in some cases appears to produce Core for this example by > constructing a case analysis on `x`, replicating `do_something` in every > branch, > > {{{#!hs > $wa_r3UQ > :: GHC.Prim.Char# > -> GHC.Prim.State# GHC.Prim.RealWorld > -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) > [GblId, Arity=2, Str=DmdType ] > $wa_r3UQ = > \ (ww_s3TD :: GHC.Prim.Char#) > (w_s3TA [OS=OneShot] :: GHC.Prim.State# GHC.Prim.RealWorld) -> > case ww_s3TD of _ [Occ=Dead] { > __DEFAULT -> (# w_s3TA, GHC.Tuple.() #); > '$' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl2_r3Uv GHC.Types.True w_s3TA; > ... > '_' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl20_r3UN GHC.Types.True w_s3TA; > '~' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl22_r3UP GHC.Types.True w_s3TA > } > }}} > > This seems to be sub-optimal for instruction cache efficiency, the number > of branches in generated machine code, code size, and understandability > of the resulting Core. I would have expected something like, > > {{{#!hs > f x = > let p = pred x > in case p of > True -> do_something > False -> do_something_else > }}} New description: Consider a case analysis like this, {{{#!hs predicate c = c == '-' || c == '_' || c == '.' || c == '~' || c == ':' || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == ',' f x | predicate x = do_something f x = do_something_else main = f 'a' }}} GHC in some cases appears to produce Core for this example by constructing a case analysis on `x`, replicating `do_something` in every branch, {{{#!hs $wa_r3UQ :: GHC.Prim.Char# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) $wa_r3UQ = \ (ww_s3TD :: GHC.Prim.Char#) (w_s3TA :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ww_s3TD of _ { __DEFAULT -> (# w_s3TA, GHC.Tuple.() #); '$' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl2_r3Uv GHC.Types.True w_s3TA; ... '_' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl20_r3UN GHC.Types.True w_s3TA; '~' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl22_r3UP GHC.Types.True w_s3TA } }}} This seems to be sub-optimal for instruction cache efficiency, the number of branches in generated machine code, code size, and understandability of the resulting Core. I would have expected something like, {{{#!hs f x = let p = pred x in case p of True -> do_something False -> do_something_else }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 05:33:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 05:33:07 -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.ea170047d1bdc9bd47fa99be1db6a1ac@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: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Consider a case analysis like this, > > {{{#!hs > predicate c = > c == '-' || c == '_' || c == '.' || c == '~' || c == ':' > || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == > ',' > > f x | predicate x = do_something > f x = do_something_else > main = f 'a' > }}} > > GHC in some cases appears to produce Core for this example by > constructing a case analysis on `x`, replicating `do_something` in every > branch, > > {{{#!hs > $wa_r3UQ > :: GHC.Prim.Char# > -> GHC.Prim.State# GHC.Prim.RealWorld > -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) > $wa_r3UQ = > \ (ww_s3TD :: GHC.Prim.Char#) > (w_s3TA :: GHC.Prim.State# GHC.Prim.RealWorld) -> > case ww_s3TD of _ { > __DEFAULT -> (# w_s3TA, GHC.Tuple.() #); > '$' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl2_r3Uv GHC.Types.True w_s3TA; > ... > '_' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl20_r3UN GHC.Types.True w_s3TA; > '~' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl22_r3UP GHC.Types.True w_s3TA > } > }}} > > This seems to be sub-optimal for instruction cache efficiency, the number > of branches in generated machine code, code size, and understandability > of the resulting Core. I would have expected something like, > > {{{#!hs > f x = > let p = pred x > in case p of > True -> do_something > False -> do_something_else > }}} New description: Consider a case analysis like this, {{{#!hs predicate c = c == '-' || c == '_' || c == '.' || c == '~' || c == ':' || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == ',' f x | predicate x = do_something f x = do_something_else main = f 'a' }}} GHC in some cases appears to produce Core for this example by constructing a case analysis on `x`, replicating `do_something` in every branch (generated by GHC 7.10), {{{#!hs $wa_r3UQ :: GHC.Prim.Char# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) $wa_r3UQ = \ (ww_s3TD :: GHC.Prim.Char#) (w_s3TA :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ww_s3TD of _ { __DEFAULT -> (# w_s3TA, GHC.Tuple.() #); '$' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl2_r3Uv GHC.Types.True w_s3TA; ... '_' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl20_r3UN GHC.Types.True w_s3TA; '~' -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout lvl22_r3UP GHC.Types.True w_s3TA } }}} This seems to be sub-optimal for instruction cache efficiency, the number of branches in generated machine code, code size, and understandability of the resulting Core. I would have expected something like, {{{#!hs f x = let p = pred x in case p of True -> do_something False -> do_something_else }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 05:34:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 05:34:56 -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.da17df4ea519a0d8f844a6528cc5d64b@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 bgamari): Interestingly enough GHC 7.8 is a bit more conservative in how it inlines: while it still produces the unneccessarily branch-y case expression, it at least doesn't inline `do_something` into each branch, {{{#!hs $wa_r3Fx = \ ww_s3EZ w_s3EW -> let { $j_s1xX $j_s1xX = \ _ -> hPutStr2 stdout (case ww_s3EZ of ds1_a1xG { __DEFAULT -> : shows21 ($wshowLitChar ds1_a1xG lvl_r3Fw); '\'' -> shows20 }) True w_s3EW } in case ww_s3EZ of _ { __DEFAULT -> (# w_s3EW, () #); '$' -> $j_s1xX void#; '&' -> $j_s1xX void#; ... '_' -> $j_s1xX void#; '~' -> $j_s1xX void# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 05:36:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 05:36:04 -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.4cf3c044333e99740b53abdaff17473f@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: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Consider a case analysis like this, > > {{{#!hs > predicate c = > c == '-' || c == '_' || c == '.' || c == '~' || c == ':' > || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == > ',' > > f x | predicate x = do_something > f x = do_something_else > main = f 'a' > }}} > > GHC in some cases appears to produce Core for this example by > constructing a case analysis on `x`, replicating `do_something` in every > branch (generated by GHC 7.10), > > {{{#!hs > $wa_r3UQ > :: GHC.Prim.Char# > -> GHC.Prim.State# GHC.Prim.RealWorld > -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) > $wa_r3UQ = > \ (ww_s3TD :: GHC.Prim.Char#) > (w_s3TA :: GHC.Prim.State# GHC.Prim.RealWorld) -> > case ww_s3TD of _ { > __DEFAULT -> (# w_s3TA, GHC.Tuple.() #); > '$' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl2_r3Uv GHC.Types.True w_s3TA; > ... > '_' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl20_r3UN GHC.Types.True w_s3TA; > '~' -> > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout lvl22_r3UP GHC.Types.True w_s3TA > } > }}} > > This seems to be sub-optimal for instruction cache efficiency, the number > of branches in generated machine code, code size, and understandability > of the resulting Core. I would have expected something like, > > {{{#!hs > f x = > let p = pred x > in case p of > True -> do_something > False -> do_something_else > }}} New description: Consider a case analysis like this, {{{#!hs predicate c = c == '-' || c == '_' || c == '.' || c == '~' || c == ':' || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == ',' f x | predicate x = do_something f x = do_something_else main = f 'a' }}} GHC in some cases appears to produce Core for this example by constructing a case analysis on `x`, replicating `do_something` in every branch (generated by GHC 7.10), {{{#!hs $wa_r3UQ = \ ww_s3TC w_s3Tz -> case ww_s3TC of _ { __DEFAULT -> (# w_s3Tz, () #); '$' -> hPutStr2 stdout lvl2_r3Uv True w_s3Tz; '&' -> hPutStr2 stdout lvl4_r3Ux True w_s3Tz; ... '_' -> hPutStr2 stdout lvl20_r3UN True w_s3Tz; '~' -> hPutStr2 stdout lvl22_r3UP True w_s3Tz } }}} This seems to be sub-optimal for instruction cache efficiency, the number of branches in generated machine code, code size, and understandability of the resulting Core. I would have expected something like, {{{#!hs f x = let p = pred x in case p of True -> do_something False -> do_something_else }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 05:39:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 05:39:43 -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.b7425aed89a5813b498eab661cc96d0d@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: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Consider a case analysis like this, > > {{{#!hs > predicate c = > c == '-' || c == '_' || c == '.' || c == '~' || c == ':' > || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == > ',' > > f x | predicate x = do_something > f x = do_something_else > main = f 'a' > }}} > > GHC in some cases appears to produce Core for this example by > constructing a case analysis on `x`, replicating `do_something` in every > branch (generated by GHC 7.10), > > {{{#!hs > $wa_r3UQ = > \ ww_s3TC w_s3Tz -> > case ww_s3TC of _ { > __DEFAULT -> (# w_s3Tz, () #); > '$' -> hPutStr2 stdout lvl2_r3Uv True w_s3Tz; > '&' -> hPutStr2 stdout lvl4_r3Ux True w_s3Tz; > ... > '_' -> hPutStr2 stdout lvl20_r3UN True w_s3Tz; > '~' -> hPutStr2 stdout lvl22_r3UP True w_s3Tz > } > }}} > > This seems to be sub-optimal for instruction cache efficiency, the number > of branches in generated machine code, code size, and understandability > of the resulting Core. I would have expected something like, > > {{{#!hs > f x = > let p = pred x > in case p of > True -> do_something > False -> do_something_else > }}} New description: Consider a case analysis like this, {{{#!hs predicate c = c == '-' || c == '_' || c == '.' || c == '~' || c == ':' || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == ',' f x | predicate x = do_something f x = do_something_else main = f 'a' }}} GHC in some cases appears to produce Core for this example by constructing a case analysis on `x`, replicating `do_something` in every branch (generated by GHC 7.10), {{{#!hs $wa_r3UQ = \ ww_s3TC w_s3Tz -> case ww_s3TC of _ { __DEFAULT -> (# w_s3Tz, () #); '$' -> hPutStr2 stdout lvl2_r3Uv True w_s3Tz; '&' -> hPutStr2 stdout lvl4_r3Ux True w_s3Tz; ... '_' -> hPutStr2 stdout lvl20_r3UN True w_s3Tz; '~' -> hPutStr2 stdout lvl22_r3UP True w_s3Tz } }}} In some cases where `do_something` is large this can lead to a substantial increase in code size. There are really two issues here, 1. That a branch-y case analysis is being used for a boolean condition 2. That `do_something` is being inlined into each branch This seems to be sub-optimal for instruction cache efficiency, the number of branches in generated machine code, and understandability of the resulting Core. I would have expected something like, {{{#!hs f x = let p = pred x in case p of True -> do_something False -> do_something_else }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 06:09:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 06:09:18 -0000 Subject: [GHC] #10121: operational semantics is incomplete? Message-ID: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> #10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | 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 was trying to read `docs/core-spec/core-spec.pdf` to understand the operational semantics for core language. So I started off by playing with operational semantics rules manually. But I found the following expression gets stuck: {{{#!hs v1 = let fix = \f -> let x = f x in x pf = \f x -> if x == 0 then x else f (pred x) in (fix pf) 2 -- S_LETNONREC v2 = ((\f -> let x = f x in x) (\f x -> if x == 0 then x else f (pred x))) 2 -- S_APP v3 = (let x = (\f x -> if x == 0 then x else f (pred x)) x in x) 2 -- S_APP; S_LETREC v4 = (let x = (\f x -> if x == 0 then x else f (pred x)) x in (\f x -> if x == 0 then x else f (pred x)) x) 2 -- S_APP v5 = (let x = (\f x -> if x == 0 then x else f (pred x)) x in (\x1 -> if x1 == 0 then x1 else x (pred x1))) 2 }}} at this point `x` is not a free variable so `S_LETRECRETURN` cannot be applied. Did I make it wrong or some rules are missing for the operational semantics? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 08:26:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 08:26:53 -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.bb8b7dde2fe5fdc1b4abe64267953dd1@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 nomeata): The GHC 7.8 code looks good to me ? I would expect later stages in the pipeline to make good code from such a case on an enumeration type. Did you have a look at the actual generated code for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 08:27:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 08:27:53 -0000 Subject: [GHC] #10121: operational semantics is incomplete? In-Reply-To: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> References: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> Message-ID: <060.7d53d3b561ced60871cb31efe589b092@haskell.org> #10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | Owner: goldfiere 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 nomeata): * owner: => goldfiere Comment: (Making Richard aware of this ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 08:33:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 08:33:00 -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.3cd53a4140034ed7e470382414f0245d@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 nomeata): Oh, and did you check whether in 7.10, GHC would duplicate code of arbitrary size into the case alternatives? That would of course be quite wrong. Can you attach a nice small example to play around with? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 08:48:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 08:48:16 -0000 Subject: [GHC] #10106: GHC doesn't warn on typos in language pragmas In-Reply-To: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> References: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> Message-ID: <060.14ab3b3bcc61a3710703ddd08e6b10bb@haskell.org> #10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #10076 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): > Maybe we need some kind of in-between thing, say a "prominent warning". It is like a warning in that it does not halt compilation. But it is not suppressed by errors. Then a mis-spelled pragma could be a "prominent warning". Somehow I don't like that idea. Seems to complicate things even more. #10076 also gives an example where a warning should not be suppressed in the presence of errors. That would also have to become "prominent warning" and I believe that with time we would discover more such cases, all of which would have to be turned into "prominent warnings". The idea of simply not suppressing warnings in the presence of errors seems to be a better solution, unless I'm missing something? But I agree that these seven levels of severity should be cleaned. Ideally - looking at packages like `log4j` for Java - the whole tracing mechanism should be integrated into one with error and warning reporting mechanism but that would be an enormous task and realistically I don't expect this to happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 11:48:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 11:48:44 -0000 Subject: [GHC] #10122: PolyKinds: inferred type not as polymorphic as possible Message-ID: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> #10122: PolyKinds: inferred type not as polymorphic as possible -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- In the user's guide on [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/kind- polymorphism.html kind polymorphism] the following example is presented: {{{#!hs f1 :: (forall a m. m a -> Int) -> Int -- f1 :: forall (k:BOX). -- (forall (a:k) (m:k->*). m a -> Int) -- -> Int }}} "Here in f1 there is no kind annotation mentioning the polymorphic kind variable, so k is generalised at the top level of the signature for f1, making the signature for f1 is as polymorphic as possible." When I ask GHCi for the type of `f1`, it is however not as polymorphic as possible: {{{ > :t f1 f1 :: (forall a (m :: * -> *). m a -> Int) -> Int }}} Trying to compile the following program: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ExplicitForAll #-} {-# LANGUAGE Rank2Types #-} module PolyFail where f :: (forall a m. m a -> Int) -> Int f g = g (Just 3) }}} Results in this error: {{{ [1 of 1] Compiling PolyFail ( PolyFail.hs, PolyFail.o ) PolyFail.hs:8:10: Kind incompatibility when matching types: m0 :: k -> * Maybe :: * -> * Expected type: m0 a0 Actual type: Maybe a1 Relevant bindings include g :: forall (a :: k) (m :: k -> *). m a -> Int (bound at PolyFail.hs:8:3) f :: (forall (a :: k) (m :: k -> *). m a -> Int) -> Int (bound at PolyFail.hs:8:1) In the first argument of ?g?, namely ?(Just 3)? In the expression: g (Just 3) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 14:41:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 14:41:19 -0000 Subject: [GHC] #10121: operational semantics is incomplete? In-Reply-To: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> References: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> Message-ID: <060.051e941c8dd2542972189a5d05c4afbd@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: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: goldfiere => goldfire Comment: Good point. The operational semantics are just wrong around `letrec`. Will think about this a little later, but a suggestion for a fix is welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 15:10:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 15:10:04 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.ffcac311ccb00c772e4a30c7fe0821a2@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9621 | Test Case: | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Changes (by George): * status: infoneeded => closed * resolution: => fixed Comment: It has been decided that we will move do this for 7.10.1, see https://mail.haskell.org/pipermail/libraries/2015-February/025009.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 16:29:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 16:29:51 -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.40312e4895eb369409c02d1456c8b3d2@haskell.org> #10122: PolyKinds: inferred type not as polymorphic as possible -------------------------------------+------------------------------------- Reporter: thomie | 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: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: I don't think there is actually a bug here, although the lack of explicit forall-bound kind variables is certainly unpleasant, and one could argue that the current behaviour may not be the most useful one. If you turn on `-XPolyKinds` in GHCi (note that it is not enough to load a module with `LANGUAGE PolyKinds`) you should find that `:t f1` gives the right answer, at least it does in 7.10-rc1. Without `-XPolyKinds`, the kind polymorphism is correctly eliminated. Moreover, the error in your `PolyFail` example is exactly what the user manual documentation would suggest. The fact that "k is generalised at the top level of the signature for f1" means that `f1` must work for all `k`, but your implementation assumes `k` is `*`. In the usual way of higher- rank types, making the signature for f1 as polymorphic as possible amounts to placing the most restrictions on the function's definition. Suggestions for how to make this clearer in the documentation are welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 19:15:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 19:15:29 -0000 Subject: [GHC] #10026: wiki formatting doc does not mention language option In-Reply-To: <048.ac2aa181d221a581209e7b02b7b58bf4@haskell.org> References: <048.ac2aa181d221a581209e7b02b7b58bf4@haskell.org> Message-ID: <063.c6105393d7acea3085ed65689d4cea55@haskell.org> #10026: wiki formatting doc does not mention language option -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: Component: Trac & Git | 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 lspitzner): * status: new => patch Comment: oh, i do have write access, neat. changed stuff around to mention the syntax highlighting syntax earlier. this seems to be more use-friendly. i hope not to have destroyed some elaborate reason behind the existing structure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 19:49:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 19:49:34 -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.bbfef3794a88d1c86dc374bebb4d175d@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: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: Thanks, you're right. I indeed did not set `-XPolyKinds` in GHCi, and didn't fully appreciate the difference between the types of `f1` and `f2`: {{{ f1 :: (forall (a::k) (m::k->*). m a -> Int) -> Int f2 :: (forall (k::BOX) (a::k) (m::k->*). m a -> Int) -> Int }}} I asked a stackoverflow [http://stackoverflow.com/questions/28772695 /rankntypes-and-polykinds question] about this, so that the answer will be easier to find. Possible documentation improvements: * an explanation or link to an explanation for `BOX` is missing (see 'Datatype promotion'). * the documentation shows the initial `forall (k:BOX)` in `f1`'s type, but GHCi and GHC error message leave it out. This could be made more clear. * the inferred type signatures show `:` instead of `::`, unnecessarily. * maybe add one more sentence about the implications the placement of the `kind forall`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 27 20:05:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Feb 2015 20:05:18 -0000 Subject: [GHC] #10026: wiki formatting doc does not mention language option In-Reply-To: <048.ac2aa181d221a581209e7b02b7b58bf4@haskell.org> References: <048.ac2aa181d221a581209e7b02b7b58bf4@haskell.org> Message-ID: <063.685caad671de3685dfaa0f862567349d@haskell.org> #10026: wiki formatting doc does not mention language option -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: Component: Trac & Git | 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 thomie): * status: patch => closed * resolution: => fixed Comment: Looks good to me. Please edit away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 00:48:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 00:48:12 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.8f57fcf9537fa46069d323ab6c565643@haskell.org> #9886: 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): It seems the 64 bit primpos are *only* needed on 32 bit architectures and then only for the native code generators. For x86 via the native code generator we needed #9346 as mentioned by @tibbe, but the arm backend did need anything because that omly compilers via LLVM. That leaves PowerPC as the remaining 32 bit architecture with an NCG. However, if I hack the 64 bit primops like (for example) this: {{{#!c StgWord64 hs_atomic_add64(volatile StgWord64 *x, StgWord64 val) { #if WORD_SIZE_IN_BITS == 32 printf ("%s : %s not implemented.\n", __FILE__, __func__) ; exit (1); #else return __sync_fetch_and_add(x, val); #endif } }}} then building the compiler runs to completion and futhermore, the one test for these atomic primops, `testsuite/tests/concurrent/should_run/AtomicPrimops.hs` passes. It turns out this test operates on Int which on 32 bit platforms is a 32 bit value. This makes me wonder if its worth the trouble of implementing these if they aren't used anywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 08:09:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 08:09:08 -0000 Subject: [GHC] #10123: GHCi won't start in Powershell ISE Message-ID: <043.a9eeffae8144a34b6827048ccb008cf5@haskell.org> #10123: GHCi won't start in Powershell ISE -------------------------------------+------------------------------------- Reporter: qwfy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: powershell | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- 1. Start Powershell ISE (Windows PowerShell ISE Host 4.0 on Windows 8.1) 2. Type "ghci" You will see the output: {{{ 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. }}} After `Loading package base ... linking ... done.`, GHCi just hangs, won't continue, the prompt is never displayed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 08:12:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 08:12:32 -0000 Subject: [GHC] #4471: Incorrect Unicode output on Windows Console In-Reply-To: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> References: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> Message-ID: <061.e77f6563026c2665acd0c00ccac50caf@haskell.org> #4471: Incorrect Unicode output on Windows Console -------------------------------------+------------------------------------- Reporter: sankeld | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by qwfy): * priority: low => high * milestone: 7.12.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 08:13:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 08:13:46 -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.fc196841253aac152e8bce80e9705855@haskell.org> #10123: GHCi won't start in Powershell ISE -------------------------------------+------------------------------------- Reporter: qwfy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: powershell Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by qwfy: Old description: > 1. Start Powershell ISE (Windows PowerShell ISE Host 4.0 on Windows 8.1) > 2. Type "ghci" > > You will see the output: > > {{{ > 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. > }}} > > After `Loading package base ... linking ... done.`, GHCi just hangs, > won't continue, the prompt is never displayed. New description: To reproduce, 1. Start Powershell ISE (Windows PowerShell ISE Host 4.0 on Windows 8.1) 2. Type "ghci" You will see the output: {{{ 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. }}} After `Loading package base ... linking ... done.`, GHCi just hangs, won't continue, the prompt is never displayed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 09:07:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 09:07:14 -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.a15f1ff4f318d1645d939bdea2aa2a05@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): Oh yes. Actually I knew that before but in this case it just says "panic" rather than looping so I thought it was irrlevant. Maybe fix the docs? Also an idea: Maybe we can do positivity analysis on data types just like Agda. We don't have to refuse it, just add a check when compiling functions that deal with it (and maybe a warning?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 12:15:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 12:15:37 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.3a4497dcbcfd88e1b546f7fac3ceacdc@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- 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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adam.gundry@? (removed) * cc: adamgundry (added) Comment: It occurred to me in passing today that this would be a nice application of typechecker plugins. They should let us experiment with the type inference issues fairly easily. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 15:53:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 15:53:48 -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.6303ad8135b92878f13490f8ef10d104@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 bgamari): nomeata, This is my toy example, {{{#!hs predicate c = c == '-' || c == '_' || c == '.' || c == '~' || c == ':' || c == '@' || c == '&' || c == '=' || c == '+' || c == '$' || c == ',' f x | predicate x = print x f x = return () {-# NOINLINE f #-} main = f 'a' }}} This was derived from https://github.com/aristidb/http- types/blob/4c9fc3d136b2bc18fe126adc3902dd7e7685ae62/Network/HTTP/Types/URI.hs (in particular `urlEncodeBuilder`'s check of `unreservedPI'`. Here GHC doesn't inline the bodies but it does create a unique body for each branch of the case, {{{#!hs case ipv1_ijS6 of wild3_X1h { __DEFAULT -> ... __word 36 -> lvl_rkUl `cast` ...; __word 38 -> lvl1_rkUm `cast` ...; __word 43 -> lvl2_rkUn `cast` ...; __word 44 -> lvl3_rkUo `cast` ...; __word 45 -> lvl4_rkUp `cast` ...; __word 46 -> lvl5_rkUq `cast` ...; __word 58 -> lvl6_rkUr `cast` ...; __word 61 -> lvl7_rkUs `cast` ...; __word 64 -> lvl8_rkUt `cast` ...; __word 95 -> lvl9_rkUu `cast` ...; __word 126 -> lvl10_rkUv `cast` ... } }}} Where each of the branches looks like this, {{{#!hs lvl2_rkUn :: forall r_ij1U. Data.ByteString.Builder.Internal.BuildStep r_ij1U -> Data.ByteString.Builder.Internal.BufferRange -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Data.ByteString.Builder.Internal.BuildSignal r_ij1U #) lvl2_rkUn = \ (@ r_ij1U) (eta_ij1V :: Data.ByteString.Builder.Internal.BuildStep r_ij1U) (eta1_ij1W :: Data.ByteString.Builder.Internal.BufferRange) (eta2_ij1X :: GHC.Prim.State# GHC.Prim.RealWorld) -> case eta1_ij1W of _ { Data.ByteString.Builder.Internal.BufferRange dt_ij27 dt1_ij28 -> case GHC.Prim.tagToEnum# (GHC.Prim.<# (GHC.Prim.minusAddr# dt1_ij28 dt_ij27) 1) of _ { False -> case GHC.Prim.writeWord8OffAddr# dt_ij27 0 (__word 43) eta2_ij1X of s2_ij40 { __DEFAULT -> ((eta_ij1V (Data.ByteString.Builder.Internal.BufferRange (GHC.Prim.plusAddr# dt_ij27 1) dt1_ij28)) `cast` ...) s2_ij40 }; True -> (# eta2_ij1X, Data.ByteString.Builder.Internal.BufferFull 1 dt_ij27 ((\ (ds_ij2P :: Data.ByteString.Builder.Internal.BufferRange) (eta3_ij2Q :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ds_ij2P of _ { Data.ByteString.Builder.Internal.BufferRange dt3_ij2T dt4_ij2U -> case GHC.Prim.writeWord8OffAddr# dt3_ij2T 0 (__word 43) eta3_ij2Q of s2_ij40 { __DEFAULT -> ((eta_ij1V (Data.ByteString.Builder.Internal.BufferRange (GHC.Prim.plusAddr# dt3_ij2T 1) dt4_ij2U)) `cast` ...) s2_ij40 } }) `cast` ...) #) } } }}} differing only in the `(__word 43)` terms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 16:34:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 16:34:20 -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.b386392d1d1820687ce8dae4ace5ebcb@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 bgamari): I'm unsure of whether it's reasonable to expect the compiler to know that it's not worth specializing the case analysis on the character `c`. For instance, `do_something` may also branch on the character; if the compiler specialized then it could eliminate the branch inside of `do_something`. However, it would be nice if the compiler gave us the tools to force the sort of behavior we want. For instance, consider an identity-like function `evalThis :: a -> a`. This would prevent the compiler from "breaking up" the term in the course of optimization. For instance, {{{#!hs f c = let pred = evalThis $ c == 'a' || c == 'b' || c == 'c' :: Bool in case pred of True -> ... False -> ... }}} would prevent the compiler from using the "insides" of `pred` in the case analysis, ensuring that somewhere in the resulting executable there would be boolean value `pred` which would then be matched against. This is obviously a pretty big hammer, but it might be nice to have every once in a while. Perhaps such a facility already exists? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 17:24:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 17:24:31 -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.4fb25b60fd988c4718f81ec6f91e9dda@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 bgamari): Well, of course there's always a `{-# NOINLINE pred #-}` pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 18:13:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 18:13:26 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches Message-ID: <046.a2efb21732640768a877c0ce17a28486@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 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 example, {{{#!hs f :: Int -> Bool f a = case a of 1 -> True 5 -> True 8 -> True 9 -> True 11 -> True 19 -> True _ -> False {-# NOINLINE f #-} main = print $ f 8 }}} This gets lowered to the following Core (by GHC 7.8), {{{#!hs f f = \ a_s3EH -> case a_s3EH of _ { I# ds_s3EJ -> case ds_s3EJ of _ { __DEFAULT -> False; 1 -> True; 5 -> True; 8 -> True; 9 -> True; 11 -> True; 19 -> True } } }}} I have expected GHC to lower this into a nice string of logical operations, with perhaps a couple of branches at the end to determine the result. Unfortunately, this is not what happens. Instead the C-- is a sea of branches, {{{ c3F7: _s3EK::I64 = I64[R1 + 7]; if (%MO_S_Lt_W64(_s3EK::I64, 9)) goto c3Fz; else goto c3FA; c3Fz: if (%MO_S_Lt_W64(_s3EK::I64, 5)) goto c3Fq; else goto c3Fr; c3Fq: if (_s3EK::I64 != 1) goto c3Ff; else goto c3Fg; c3Fr: if (%MO_S_Lt_W64(_s3EK::I64, 8)) goto c3Fn; else goto c3Fo; c3Fn: if (_s3EK::I64 != 5) goto c3Ff; else goto c3Fg; c3Fo: if (_s3EK::I64 != 8) goto c3Ff; else goto c3Fg; c3FA: if (%MO_S_Lt_W64(_s3EK::I64, 11)) goto c3Fw; else goto c3Fx; c3Fw: if (_s3EK::I64 != 9) goto c3Ff; else goto c3Fg; c3Fx: if (%MO_S_Lt_W64(_s3EK::I64, 19)) goto c3Ft; else goto c3Fu; c3Ft: if (_s3EK::I64 != 11) goto c3Ff; else goto c3Fg; c3Fu: if (_s3EK::I64 != 19) goto c3Ff; else goto c3Fg; c3Ff: R1 = False_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c3Fg: R1 = True_closure+2; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; ... }}} Which gets turned into the branchy assembler that you would expect. To my surprise even the LLVM backend isn't able to bring this back into a branchless form. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 18:21:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 18:21:00 -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.c2034e97128ff67224df3c7bb8bcfd2c@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 bgamari): It seems like we really should be able to do better generating code for the case analyses above. I've opened #10124 to track this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 18:21:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 18:21: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.5078f92b6b404032f99cbce9e2737c05@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: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 18:25:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 18:25:05 -0000 Subject: [GHC] #6135: Unboxed Booleans In-Reply-To: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> References: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> Message-ID: <058.75af0b9de70b621688e4791d9f18b12c@haskell.org> #6135: Unboxed Booleans -------------------------------------+------------------------------------- Reporter: benl | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 8103, 8103 | Test Case: Related Tickets: #605 | primops/should_run/T6135 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 18:35:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 18:35:09 -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.8209bb645178caba8a8e11827e23cae5@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: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 18:37:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 18:37:08 -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.e925c9ed247f66d1941b001649504dc7@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: -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #6135 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 28 18:42:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Feb 2015 18:42:28 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.1d84becc2c204e64eaef2b3efebb9f93@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | 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: #1498 | Blocking: 8317 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler