From ghc-devs at haskell.org Sat Nov 1 06:26:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 06:26:37 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.ef3da579859a42e2ffae1a616152199c@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I managed to boil it down a bit more -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 11:18:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 11:18:25 -0000 Subject: [GHC] #9705: Panic on a pattern synonym in a class In-Reply-To: <047.614ec39c173b8238a9064e76b118d842@haskell.org> References: <047.614ec39c173b8238a9064e76b118d842@haskell.org> Message-ID: <062.200070751b0d98fd291476e9fe7ed033@haskell.org> #9705: Panic on a pattern synonym in a class -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"e5ba36080d08791f44e3bed37721f702e242af96/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e5ba36080d08791f44e3bed37721f702e242af96" rnMethodBind: reject pattern synonyms in instance definitions (fixes #9705) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 11:26:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 11:26:46 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.d2a46ad726cb2da4b82f79406a2cc99e@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => patch Comment: Implementation based on the discussion above is now pushed to `wip/T9732`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 11:27:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 11:27:13 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.738ea9fd716dca280e12cf515d934361@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: pattern synonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 11:27:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 11:27:46 -0000 Subject: [GHC] #9705: Panic on a pattern synonym in a class In-Reply-To: <047.614ec39c173b8238a9064e76b118d842@haskell.org> References: <047.614ec39c173b8238a9064e76b118d842@haskell.org> Message-ID: <062.a601a094391ed6175befb6b7517823cf@haskell.org> #9705: Panic on a pattern synonym in a class -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 11:30:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 11:30:48 -0000 Subject: [GHC] #9705: Panic on a pattern synonym in a class In-Reply-To: <047.614ec39c173b8238a9064e76b118d842@haskell.org> References: <047.614ec39c173b8238a9064e76b118d842@haskell.org> Message-ID: <062.55486b9fdccfc2ff6f24426af5d20db7@haskell.org> #9705: Panic on a pattern synonym in a class -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => pattern synonyms * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 13:18:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 13:18:49 -0000 Subject: [GHC] #9752: Output unicode characters Message-ID: <046.63733476c3fa2fe192792605d468038e@haskell.org> #9752: Output unicode characters -------------------------------------+------------------------------------- Reporter: pokiaka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: unicode, stderr, | Operating System: Windows errors, output, printing, | Type of failure: Incorrect encoding, utf, utf8 | result at runtime Architecture: Unknown/Multiple | Test Case: Difficulty: Easy (less than 1 | Blocking: hour) | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- When using UnicodeHaskell and having an error with a unicode symbol lurking around, GHC fails to print its name. So e.g. you get a message of an error "In the first argument of (: commitBuffer: invalid argument (invalid character)". I am not certain, but I think that the fix would be to `hSetEncoding stderr utf8` before the output is printed. If so, hopefully it should be a quick easy fix. (And perhaps it would be appropriate to do the same for stdout as-well, or just when UnicodeSyntax is on). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 13:20:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 13:20:29 -0000 Subject: [GHC] #5435: GHCi linker should run constructors for linked libraries In-Reply-To: <046.8b82a36416a611e39b118853f0f9d2f0@haskell.org> References: <046.8b82a36416a611e39b118853f0f9d2f0@haskell.org> Message-ID: <061.8ce1d91b4ce4540cd5821d7aa4d74bd0@haskell.org> #5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"a47ff8be5aa78aff2eb80d5f91e294f52ea392e0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a47ff8be5aa78aff2eb80d5f91e294f52ea392e0" Fixed T5435_dyn_asm on Windows. The test code was not in sync with the expected output. Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D403 GHC Trac Issues: #5435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 13:57:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 13:57:06 -0000 Subject: [GHC] #9752: Output unicode characters In-Reply-To: <046.63733476c3fa2fe192792605d468038e@haskell.org> References: <046.63733476c3fa2fe192792605d468038e@haskell.org> Message-ID: <061.980e95e02e46fd2640c4fddfefcf6892@haskell.org> #9752: Output unicode characters -------------------------------------+------------------------------------- Reporter: pokiaka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: unicode, stderr, Operating System: Windows | errors, output, printing, encoding, Type of failure: Incorrect | utf, utf8 result at runtime | Architecture: Unknown/Multiple Test Case: | Difficulty: Easy (less than 1 Blocking: | hour) Differential Revisions: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thomie): Could you add an example please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 16:39:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 16:39:51 -0000 Subject: [GHC] #9698: GHC_PACKAGE_PATH should be more lenient for empty paths In-Reply-To: <047.c636c8193d3a0be6c7f17bc6acc215b1@haskell.org> References: <047.c636c8193d3a0be6c7f17bc6acc215b1@haskell.org> Message-ID: <062.362c20406794ada0cd79eeac94b1ef8c@haskell.org> #9698: GHC_PACKAGE_PATH should be more lenient for empty paths -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: ghc-pkg | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #2521 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => ghc-pkg * related: => #2521 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 18:16:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 18:16:56 -0000 Subject: [GHC] #9752: Output unicode characters In-Reply-To: <046.63733476c3fa2fe192792605d468038e@haskell.org> References: <046.63733476c3fa2fe192792605d468038e@haskell.org> Message-ID: <061.bcfb7664b327b779af33c833997173dc@haskell.org> #9752: Output unicode characters -------------------------------------+------------------------------------- Reporter: pokiaka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: unicode, stderr, Operating System: Windows | errors, output, printing, encoding, Type of failure: Incorrect | utf, utf8 result at runtime | Architecture: Unknown/Multiple Test Case: | Difficulty: Easy (less than 1 Blocking: | hour) Differential Revisions: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by pokiaka): Replying to [comment:1 thomie]: > Could you add an example please? Definitely. Source: {{{ {-# LANGUAGE UnicodeSyntax #-} module Example where (?) = elem oops = 20 ? (10,20,30) }}} Output: {{{ [1 of 1] Compiling Example ( Example.hs, Example.o ) Example.hs:4:13: Couldn't match expected type `[a0]' with actual type `(t0, t1, t2)' In the second argument of `(: commitBuffer: invalid argument (invalid character) }}} As you can see, it prints the error where it should have printed `?`, and then immediately stopped printing, discarding any next messages.
Same behavior on GHCi, and WinGHCi, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 19:14:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 19:14:56 -0000 Subject: [GHC] #9753: Segmentation fault when applying ** to a complex number Message-ID: <052.31cc10dcfae3d94842317171c24a87bb@haskell.org> #9753: Segmentation fault when applying ** to a complex number ---------------------------------+--------------------------------------- Reporter: AlexeiKopylov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: ia64 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+--------------------------------------- Rising a negative complex number to a power using {{{**}}} in ghci causes a segmentation fault: {{{ $ ghci 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> :m +Data.Complex Prelude Data.Complex> (-1) ** 1 :: Complex Double Segmentation fault }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 19:16:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 19:16:36 -0000 Subject: [GHC] #9753: Segmentation fault when applying ** to a complex number In-Reply-To: <052.31cc10dcfae3d94842317171c24a87bb@haskell.org> References: <052.31cc10dcfae3d94842317171c24a87bb@haskell.org> Message-ID: <067.3eb4dc720c9a26d01746fd5962a06f0a@haskell.org> #9753: Segmentation fault when applying ** to a complex number ----------------------------------------+--------------------------- Reporter: AlexeiKopylov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: ia64 Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+--------------------------- Changes (by AlexeiKopylov): * failure: None/Unknown => GHCi crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 19:18:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 19:18:58 -0000 Subject: [GHC] #9703: Add missing calling conventions to Template Haskell In-Reply-To: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> References: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> Message-ID: <059.298444fe88b6d9437ebbf7855de25f88@haskell.org> #9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ekmett Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D353 | -------------------------------------+------------------------------------- Comment (by luite): Replying to [comment:2 mtolly]: > Just reported this a bit ago :) https://ghc.haskell.org/trac/ghc/ticket/9694 Ah sorry, I missed that one. There is a workaround in GHCJS that lets you output javascript imports by encoding them with a special name, see https://github.com/ghcjs/ghcjs- ffiqq/blob/75c7ee1b09c019c897a30d87713d023e8e1fc43f/src/GHCJS/Foreign/QQ.hs#L100 . GHCJS picks this up in the desugarer and replaces it with a `javascript` import. This will probably be removed when `template-haskell` supports the calling convention directly. I'm not sure if a `String` field is all that useful, since it'd have to be possible to convert it between the TH and GHC representation. Converting might still be possible with `Read`/`Show` or similar, but that doesn't sound very attractive to me. I'd say it's better to keep the current approach until there's a real need for a flexible `String` constructor, like a non-GHC compiler supporting TH with very different calling conventions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 19:33:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 19:33:28 -0000 Subject: [GHC] #9753: Segmentation fault when applying ** to a complex number In-Reply-To: <052.31cc10dcfae3d94842317171c24a87bb@haskell.org> References: <052.31cc10dcfae3d94842317171c24a87bb@haskell.org> Message-ID: <067.e369afbc2e6e30302f82a0bde6b238d5@haskell.org> #9753: Segmentation fault when applying ** to a complex number ----------------------------------------+--------------------------- Reporter: AlexeiKopylov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: ia64 Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+--------------------------- Old description: > Rising a negative complex number to a power using {{{**}}} in ghci causes > a segmentation fault: > {{{ > $ ghci > 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> :m +Data.Complex > Prelude Data.Complex> (-1) ** 1 :: Complex Double > Segmentation fault > }}} New description: Rising a negative complex number to a power using {{{**}}} in ghci causes a segmentation fault: {{{ $ ghci 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> :m +Data.Complex Prelude Data.Complex> (-1) ** 1 :: Complex Double Segmentation fault }}} -- Comment (by thomie): I can not reproduce this problem on Linux, neither with 7.6.3, nor with 7.8.3: {{{ $ ghci GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m +Data.Complex Prelude Data.Complex> (-1) ** 1 :: Complex Double (-1.0) :+ (-1.2246467991473532e-16) }}} Can you try with GHC 7.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 19:53:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 19:53:15 -0000 Subject: [GHC] #9752: Output unicode characters on Windows (was: Output unicode characters) In-Reply-To: <046.63733476c3fa2fe192792605d468038e@haskell.org> References: <046.63733476c3fa2fe192792605d468038e@haskell.org> Message-ID: <061.cd9c2093bdfe66c74c955c01766dfd48@haskell.org> #9752: Output unicode characters on Windows -------------------------------------+------------------------------------- Reporter: pokiaka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: unicode, stderr, Operating System: Windows | errors, output, printing, encoding, Type of failure: Incorrect | utf, utf8 result at runtime | Architecture: Unknown/Multiple Test Case: | Difficulty: Easy (less than 1 Blocking: | hour) Differential Revisions: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thomie): * cc: gintas (added) Old description: > When using UnicodeHaskell and having an error with a unicode symbol > lurking around, GHC fails to print its name. > So e.g. you get a message of an error "In the first argument of > (: commitBuffer: invalid argument (invalid character)". > > I am not certain, but I think that the fix would be to `hSetEncoding > stderr utf8` before the output is printed. If so, hopefully it should be > a quick easy fix. > (And perhaps it would be appropriate to do the same for stdout as-well, > or just when UnicodeSyntax is on). New description: On Windows, when having an error with a unicode symbol lurking around, GHC fails to print its name. So e.g. you get a message of an error "In the first argument of (: commitBuffer: invalid argument (invalid character)". I am not certain, but I think that the fix would be to `hSetEncoding stderr utf8` before the output is printed. If so, hopefully it should be a quick easy fix. (And perhaps it would be appropriate to do the same for stdout as-well). -- Comment: Can not reproduce on Linux with GHC 7.8.3, so this seems like a Windows only problem. By the way: you shouldn't need the UnicodeSyntax extension [1] for above example to work/fail. [1] https://www.haskell.org/ghc/docs/latest/html/users_guide/syntax- extns.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 19:53:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 19:53:37 -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.5e0e93aca40032cacdeddc2e77494a18@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 | Version: 7.8.2 (Type checker) | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #8634 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Should the ticket be reopened not to get lost and final decision to be stated? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 20:23:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 20:23:03 -0000 Subject: [GHC] #9753: Segmentation fault when applying ** to a complex number In-Reply-To: <052.31cc10dcfae3d94842317171c24a87bb@haskell.org> References: <052.31cc10dcfae3d94842317171c24a87bb@haskell.org> Message-ID: <067.9b8b966bae0e08abbeaa60de2d27615e@haskell.org> #9753: Segmentation fault when applying ** to a complex number ----------------------------------------+--------------------------- Reporter: AlexeiKopylov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: ia64 Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+--------------------------- Comment (by AlexeiKopylov): I've updated to 7.8.3, and the bag is disappeared. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 20:36:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 20:36:01 -0000 Subject: [GHC] #9753: Segmentation fault when applying ** to a complex number In-Reply-To: <052.31cc10dcfae3d94842317171c24a87bb@haskell.org> References: <052.31cc10dcfae3d94842317171c24a87bb@haskell.org> Message-ID: <067.154c3964c34367b8bcf60654acb2400b@haskell.org> #9753: Segmentation fault when applying ** to a complex number ----------------------------------------+--------------------------- Reporter: AlexeiKopylov | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: ia64 Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Must have been fixed somewhere along the line. Sorry for the bug! There won't be any more 7.6 releases unfortunately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 22:20:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 22:20:46 -0000 Subject: [GHC] #9698: GHC_PACKAGE_PATH should be more lenient for empty paths In-Reply-To: <047.c636c8193d3a0be6c7f17bc6acc215b1@haskell.org> References: <047.c636c8193d3a0be6c7f17bc6acc215b1@haskell.org> Message-ID: <062.24be11eca8941142d2dfae88cea69a4e@haskell.org> #9698: GHC_PACKAGE_PATH should be more lenient for empty paths -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.3 Component: ghc-pkg | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #2521 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D414 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D414 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 1 23:54:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Nov 2014 23:54:53 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.640f964661f07f31298b4de8f4c7d6d9@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | 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 Nov 2 01:41:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 01:41:41 -0000 Subject: [GHC] #9752: Output unicode characters on Windows In-Reply-To: <046.63733476c3fa2fe192792605d468038e@haskell.org> References: <046.63733476c3fa2fe192792605d468038e@haskell.org> Message-ID: <061.255f8896bac48be18609b008b01dd1a0@haskell.org> #9752: Output unicode characters on Windows -------------------------------------+------------------------------------- Reporter: pokiaka | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: unicode, stderr, Operating System: Windows | errors, output, printing, encoding, Type of failure: Incorrect | utf, utf8 result at runtime | Architecture: Unknown/Multiple Test Case: | Difficulty: Easy (less than 1 Blocking: | hour) Differential Revisions: | Blocked By: | Related Tickets: #6037 -------------------------------------+------------------------------------- Changes (by thomie): * cc: gintas (removed) * status: new => closed * resolution: => duplicate * related: => #6037 Comment: Closing as a duplicate of #6037. Feel free to reopen if you think this is a different bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.f4b63f31abc4acd7be7be8c304a8fcfb@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D387 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"b174288b15300093a4356c853ce2ea0abb4876f5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b174288b15300093a4356c853ce2ea0abb4876f5" Test #8953 in th/T8953 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.2f456988fbd2f5379fb4f55f5702ad06@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D387 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"9fd19f960f37b1369f8a3453b05c1805e0057232/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9fd19f960f37b1369f8a3453b05c1805e0057232" Always use KindedTV when reifying. (#8953) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #9262: Allow free variables in reifyInstances In-Reply-To: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> References: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> Message-ID: <062.c1abaaf808cb82245877a5ab287e1c74@haskell.org> #9262: Allow free variables in reifyInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D359 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2cc593dd50197c252d87321280a04f04cc173dbc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2cc593dd50197c252d87321280a04f04cc173dbc" Bring unbound tyvars into scope during reifyInstances. Fix #9262. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #9262: Allow free variables in reifyInstances In-Reply-To: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> References: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> Message-ID: <062.2690bd18809899f1865163df56ca0c12@haskell.org> #9262: Allow free variables in reifyInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D359 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"f688f0377e13e0762d422ed3a83e74b5d39b5e13/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f688f0377e13e0762d422ed3a83e74b5d39b5e13" Test #9262 in th/T9262, and update other tests. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.0590a4222e6126c7dc3670a43b4c5dc0@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D387 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"593e8b9adc3cb6b7364bedec4e4c626eea2fcd27/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="593e8b9adc3cb6b7364bedec4e4c626eea2fcd27" Annotate reified poly-kinded tycons when necessary. (#8953) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.2e9a7a12dd64db1d8fa270ad48aaf6db@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D387 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c3ecf06018ee3d97a6536de57519af865976ce04/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c3ecf06018ee3d97a6536de57519af865976ce04" Annotate poly-kinded type patterns in instance reification. This should fix #8953. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #9084: Template Haskell should warn when it encounters an unencodable pragma In-Reply-To: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> References: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> Message-ID: <062.f940a5fc40eec2c86d874df526152131@haskell.org> #9084: Template Haskell should warn when it encounters an unencodable pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D388 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"03d61cce4d92a37a193cc1211eb7262149f22e3b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="03d61cce4d92a37a193cc1211eb7262149f22e3b" Fix #9084 by calling notHandled when unknown bits are enountered. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #9738: Handle ANN pragmas in declaration splices In-Reply-To: <047.9007fbb41f2b3d6c8fece070225de54d@haskell.org> References: <047.9007fbb41f2b3d6c8fece070225de54d@haskell.org> Message-ID: <062.e740c4c3dd512dad5fcb830e915b58de@haskell.org> #9738: Handle ANN pragmas in declaration splices -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D389 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"209baea8bc1f99b371b9ba49f5b81caa45bb34bf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="209baea8bc1f99b371b9ba49f5b81caa45bb34bf" Fix #9738, by handling {-# ANN ... #-} in DsMeta. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #9084: Template Haskell should warn when it encounters an unencodable pragma In-Reply-To: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> References: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> Message-ID: <062.1da338755bde20cd14830b6a070d3ba1@haskell.org> #9084: Template Haskell should warn when it encounters an unencodable pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D388 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17265c033707a84fd59fec61b3a370c3a427ffa3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="17265c033707a84fd59fec61b3a370c3a427ffa3" Fix testsuite output from #9084. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #9084: Template Haskell should warn when it encounters an unencodable pragma In-Reply-To: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> References: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> Message-ID: <062.fa786b61d47b9dba22d10d71fcf068be@haskell.org> #9084: Template Haskell should warn when it encounters an unencodable pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D388 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"862772b7ecfce977ffe7090659da3bd923ef946a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="862772b7ecfce977ffe7090659da3bd923ef946a" Test #9084 in th/T9084. The patch includes errors for a whole host of pragmas. But, these are generated one at a time, and it doesn't seem like a good idea to add gobs of test-cases here. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.984391e65776bd642ef16b79eac27c29@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D387 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"99882babf9bb2d73b972330b1cfa9495a029855b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="99882babf9bb2d73b972330b1cfa9495a029855b" Testsuite wibbles from fixing #8953 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 03:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 03:53:16 -0000 Subject: [GHC] #9738: Handle ANN pragmas in declaration splices In-Reply-To: <047.9007fbb41f2b3d6c8fece070225de54d@haskell.org> References: <047.9007fbb41f2b3d6c8fece070225de54d@haskell.org> Message-ID: <062.90971b98176fa088270fafe788e3d101@haskell.org> #9738: Handle ANN pragmas in declaration splices -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D389 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"752b5e216963c0e8c06aa382b695ce2215869632/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="752b5e216963c0e8c06aa382b695ce2215869632" Test #9738 in th/T9738 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 04:09:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 04:09:29 -0000 Subject: [GHC] #9084: Template Haskell should warn when it encounters an unencodable pragma In-Reply-To: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> References: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> Message-ID: <062.ab1eac60f63aff22cb05b06db9393d36@haskell.org> #9084: Template Haskell should warn when it encounters an unencodable pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D388 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"18a4a5dad3cbee3c8bb4005ec09edf401ebe294c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="18a4a5dad3cbee3c8bb4005ec09edf401ebe294c" Update release notes for #9262 #8953 #9084. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 04:09:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 04:09:29 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.e549dc8990c447e0589c7bfa9e98aaec@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D387 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"18a4a5dad3cbee3c8bb4005ec09edf401ebe294c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="18a4a5dad3cbee3c8bb4005ec09edf401ebe294c" Update release notes for #9262 #8953 #9084. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 04:09:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 04:09:29 -0000 Subject: [GHC] #9262: Allow free variables in reifyInstances In-Reply-To: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> References: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> Message-ID: <062.4715b74cc2a5f5da0a6b1e15765f4f3f@haskell.org> #9262: Allow free variables in reifyInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D359 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"18a4a5dad3cbee3c8bb4005ec09edf401ebe294c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="18a4a5dad3cbee3c8bb4005ec09edf401ebe294c" Update release notes for #9262 #8953 #9084. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 04:10:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 04:10:39 -0000 Subject: [GHC] #9262: Allow free variables in reifyInstances In-Reply-To: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> References: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> Message-ID: <062.d58bbe544b6d99756635dd6a528ad147@haskell.org> #9262: Allow free variables in reifyInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D359 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 04:11:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 04:11:07 -0000 Subject: [GHC] #9262: Allow free variables in reifyInstances In-Reply-To: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> References: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> Message-ID: <062.cd7638ae3e486cbe9a436afbbd2eb92b@haskell.org> #9262: Allow free variables in reifyInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: th/T9262 | Blocking: | Differential Revisions: Phab:D359 | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => th/T9262 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 04:11:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 04:11:55 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.3cc3656cbfc71ad2f7d05b867c08ba5c@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T8953 | Blocking: | Differential Revisions: Phab:D387 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => th/T8953 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 04:12:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 04:12:48 -0000 Subject: [GHC] #9084: Template Haskell should warn when it encounters an unencodable pragma In-Reply-To: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> References: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> Message-ID: <062.555eac44896a393e27ee86bec0b3766f@haskell.org> #9084: Template Haskell should warn when it encounters an unencodable pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T9084 | Blocking: | Differential Revisions: Phab:D388 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => th/T9084 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 04:13:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 04:13:33 -0000 Subject: [GHC] #9738: Handle ANN pragmas in declaration splices In-Reply-To: <047.9007fbb41f2b3d6c8fece070225de54d@haskell.org> References: <047.9007fbb41f2b3d6c8fece070225de54d@haskell.org> Message-ID: <062.201ba195a181e9d38f3b91514c1ffaf1@haskell.org> #9738: Handle ANN pragmas in declaration splices -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T9738 | Blocking: | Differential Revisions: Phab:D389 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => th/T9738 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 05:26:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 05:26:41 -0000 Subject: [GHC] #9742: The default definitions of foldl1 and foldr1 are too strict In-Reply-To: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> References: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> Message-ID: <060.4c3ceeef7829037a6e549107eb86eb35@haskell.org> #9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D416 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D416 Comment: This has met with a positive response on the libraries list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 09:07:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 09:07:15 -0000 Subject: [GHC] #9742: The default definitions of foldl1 and foldr1 are too strict In-Reply-To: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> References: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> Message-ID: <060.66a5610c74bd9f5e1a80f9fb93e9b41b@haskell.org> #9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D416 | -------------------------------------+------------------------------------- Comment (by thomie): Mailinglist thread: https://www.haskell.org/pipermail/libraries/2014-October/024035.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 09:44:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 09:44:37 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.d654f856f8d53c7e1b9736d013e70b78@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4114 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by VictorDenisov): * owner: => VictorDenisov -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 10:11:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 10:11:43 -0000 Subject: [GHC] #2200: big static random access arrays In-Reply-To: <043.a925e7306d93d3b9993abaf14c0d8674@haskell.org> References: <043.a925e7306d93d3b9993abaf14c0d8674@haskell.org> Message-ID: <058.80a6d4feea25582cb8dbb484ce23e4f9@haskell.org> #2200: big static random access arrays -------------------------------------+------------------------------------- Reporter: jsnx | Owner: ekmett Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.8.2 Component: Core | Keywords: static array Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * failure: => None/Unknown * component: Compiler => Core Libraries * owner: => ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 10:32:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 10:32:34 -0000 Subject: [GHC] #7330: Data Parallel Haskell (DPH) isn't usable yet. In-Reply-To: <043.4e25815c16cd5404c1599b28d973adcf@haskell.org> References: <043.4e25815c16cd5404c1599b28d973adcf@haskell.org> Message-ID: <058.145efeaf91aa62ae1f3bf8ecd37a1e44@haskell.org> #7330: Data Parallel Haskell (DPH) isn't usable yet. -------------------------------------+------------------------------------- Reporter: benl | Owner: benl Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Data | Keywords: Parallel Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 3782, | 3903, 4438, 5807, 6004, 7098, | 8023 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Data Parallel Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 10:41:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 10:41:14 -0000 Subject: [GHC] #8967: Add syntax for creating finite maps and sets In-Reply-To: <044.fe1b7f69fd77fe9c6b0017a53bbe1a36@haskell.org> References: <044.fe1b7f69fd77fe9c6b0017a53bbe1a36@haskell.org> Message-ID: <059.e5e61f1b4e402df101005b9498ddb520@haskell.org> #8967: Add syntax for creating finite maps and sets -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #436 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #436 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 11:45:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 11:45:40 -0000 Subject: [GHC] #2365: Warn about usage of `OPTIONS_GHC -XLanguageExtension` (was: Warn about suspicious flags in OPTIONS_GHC pragmas) In-Reply-To: <044.945add75703117abb32003d74d697760@haskell.org> References: <044.945add75703117abb32003d74d697760@haskell.org> Message-ID: <059.fcf896ca89d56e0f5daee1c5047f9f95@haskell.org> #2365: Warn about usage of `OPTIONS_GHC -XLanguageExtension` -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1407, #2499 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #1407 => #1407, #2499 Comment: Warnings for `{-# OPTIONS_GHC -package foo #-}` were added in #2499. This ticket is for showing a warning when `{-# OPTIONS_GHC -XLanguageExtension #-}` is used. The [https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/pragmas.html #language-pragma user guide] says: "The LANGUAGE pragma should be used instead of OPTIONS_GHC, if possible." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 11:51:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 11:51:45 -0000 Subject: [GHC] #2526: Warn about missing signatures only for exported functions (was: warn about missing signatures only for exported functions) In-Reply-To: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> References: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> Message-ID: <069.c6400112bf2f0481e2c40bcb6ef42f27@haskell.org> #2526: Warn about missing signatures only for exported functions -------------------------------------+------------------------------------- Reporter: | Owner: fergushenderson | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.8.3 Priority: lowest | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by thomie: Old description: > The -fno-warn-missing-signatures option results in warnings if signatures > are not declared for any top-level functions. > > Many Haskell users prefer to declare type signatures only for exported > functions, which are part of the module's interface, not for all > functions. It would be nice to have an option that issued warnings iff > any exported functions lacked explicit signatures. New description: The -fwarn-missing-signatures option results in warnings if signatures are not declared for any top-level functions. Many Haskell users prefer to declare type signatures only for exported functions, which are part of the module's interface, not for all functions. It would be nice to have an option that issued warnings iff any exported functions lacked explicit signatures. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 14:12:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 14:12:18 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.8e6e62edd2936cc7809b6f37634a7770@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): The following break GHC's validate (see https://phabricator.haskell.org/harbormaster/build/1562/) {{{ -- * base import Control.Monad ( unless, liftM ) import GHC.Exts import Data.Char import Control.Monad ( mplus ) -- * compiler/hsSyn import HsSyn }}} I ended up having to remove '*' from the comment for it to work: {{{ -- base import Control.Monad ( unless, liftM ) import GHC.Exts import Data.Char import Control.Monad ( mplus ) -- compiler/hsSyn import HsSyn }}} This seems to be the relevant part in Lexer.x: {{{ "-- " ~[$docsym \#] .* { lineCommentToken } "--" [^$symbol \ ] .* { lineCommentToken } -- Next, match Haddock comments if no -haddock flag "-- " [$docsym \#] .* / { ifExtension (not . haddockEnabled) } { lineCommentToken } -- Now, when we've matched comments that begin with 2 dashes and continue -- with a different character, we need to match comments that begin with three -- or more dashes (which clearly can't be Haddock comments). We only need to -- make sure that the first non-dash character isn't a symbol, and munch the -- rest of the line. "---"\-* ~$symbol .* { lineCommentToken } -- Since the previous rules all match dashes followed by at least one -- character, we also need to match a whole line filled with just dashes. "--"\-* / { atEOL } { lineCommentToken } -- We need this rule since none of the other single line comment rules -- actually match this case. "-- " / { atEOL } { lineCommentToken } }}} And it seems that there is no case for when {{{haddockEnabled}}} is true. What should be the action for such rule? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 18:04:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 18:04:04 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.adf1370316b2e6b934c0e0d3472c1523@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"c271e32eac65ee95ba1aacc72ed1b24b58ef17ad/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c271e32eac65ee95ba1aacc72ed1b24b58ef17ad" Add GHC.Prim.oneShot to allow the programer to explictitly set the oneShot flag. This helps with #7994 and will be used in left folds. Also see https://ghc.haskell.org/trac/ghc/wiki/OneShot This commit touches libraries/base/GHC/Event/Manager.hs (which used to have a local definition of the name oneShot) to avoid a shadowing error. Differential Revision: https://phabricator.haskell.org/D392 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 18:04:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 18:04:04 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.7a3dbd2aeb20ade947f274304a39e950@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"072259c78f77d6fe7c36755ebe0123e813c34457/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="072259c78f77d6fe7c36755ebe0123e813c34457" Use oneShot in the definition of foldl etc. This increases the chance of good code after fusing a left fold. See ticket #7994 and the new Note [Left folds via right fold] Differential Revision: https://phabricator.haskell.org/D393 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 18:33:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 18:33:58 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.a8b0706c817193e7cfbb6b0a3cc29e84@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Adding the following definitions made this more perspicuous to me: {{{ fromList1DF :: (List l a, List l b) => [(a,b)] -> DFProd l (Pair Unit Unit) (a, b) fromList1DF [] = DFPair (DFLeaf nil) (DFLeaf nil) fromList1DF ((a,b):xs) = case fromList1DF xs of DFPair (DFLeaf as) (DFLeaf bs) -> DFPair (DFLeaf (a `cons` as)) (DFLeaf (b `cons` bs)) fromList1GA :: (List l a, List l b) => [(a,b)] -> GAProd l (Pair Unit Unit) (a, b) fromList1GA [] = GAPair (GALeaf nil) (GALeaf nil) fromList1GA ((a,b):xs) = case fromList1GA xs of GAPair (GALeaf as) (GALeaf bs) -> GAPair (GALeaf (a `cons` as)) (GALeaf (b `cons` bs)) -- GAPair (GAPair _ _) _ -> undefined -- GAPair (GALeaf _) (GAPair _ _) -> undefined _ -> error "GADT warnings bad" }}} (Note that the one pattern in `fromList1GA` is actually complete, but #3927 bites unless we have the catchall case. The commented-out lines were my tests to make sure that other patterns were indeed inaccessible.) `fromList1DF` compiles just fine. `fromList1GA` fails with two errors, the second being {{{ /Users/rae/temp/bug/SimplerGadtVsData.hs:104:32: Couldn't match type ?l0? with ?l? ?l0? is untouchable inside the constraints ('Pair 'Unit 'Unit ~ 'Pair pra prb, (a, b) ~ (a1, b1)) bound by a pattern with constructor GAPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) b. GAProd v pra a -> GAProd v prb b -> GAProd v ('Pair pra prb) (a, b), in a case alternative at /Users/rae/temp/bug/SimplerGadtVsData.hs:103:5-34 ?l? is a rigid type variable bound by the type signature for fromList1GA :: (List l a, List l b) => [(a, b)] -> GAProd l ('Pair 'Unit 'Unit) (a, b) at /Users/rae/temp/bug/SimplerGadtVsData.hs:100:16 Expected type: l a Actual type: l0 a1 Relevant bindings include bs :: l0 b1 (bound at /Users/rae/temp/bug/SimplerGadtVsData.hs:103:32) as :: l0 a1 (bound at /Users/rae/temp/bug/SimplerGadtVsData.hs:103:20) fromList1GA :: [(a, b)] -> GAProd l ('Pair 'Unit 'Unit) (a, b) (bound at /Users/rae/temp/bug/SimplerGadtVsData.hs:101:1) In the second argument of ?cons?, namely ?as? In the first argument of ?GALeaf?, namely ?(a `cons` as)? }}} (The first is a failure about class constraints. This failure is a direct consequence of the error listed above. Indeed, I would say that the first error -- which complains about ambiguity of `l0` -- should be suppressed when we also report that `l0` is untouchable.) The problem is that GHC can't infer the result type of the GADT pattern match. Perhaps this result type somehow depends on the information we learn about `pra` and `prb` in the match, and there's no way to infer this dependency. So, GHC gives up -- this is the essence of "untouchable" variables. I think there ''is'' room for improvement here, because the GADT pattern match wasn't actually informative, in this case: all the information that comes out of the match is known beforehand, via the details of the type signature. It is perhaps conceivable to detect this corner case and not make the "global" tyvars become untouchable. I don't know if this is worth pursuing very deeply, but I think that's what's going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 18:54:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 18:54:55 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.ea564e7d61ffe3a84d9ba7a31a3d4d92@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): This also fails for type constructors: {{{ $( [d| type Foo a b = Either a b infix 5 `Foo` |]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 19:33:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 19:33:35 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.7fa6aacc0fa4c2efa76a0cef12156fea@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Harrumph. In that second case, {{{[d| infix 5 `Foo` |]}}} produces an `Exact` `RdrName` for `Foo` that names a ''data'' constructor, not a ''type'' constructor, even when only the type constructor is in scope. Then, according to `Note [dataTcOccs and Exact Names]` in !RnEnv, the `Exact` `RdrName`s are trusted to have the right namespace and, so a naive fix for this bug fails the `Foo` case. There are two possible ways forward that I see: 1. Don't trust `Exact` `RdrName`s in `dataTcOccs`. That is, when we have an `Exact` constructor name, also look for the type with same spelling. 2. Duplicate the `dataTcOccs` logic in !DsMeta. I favor (2), because code that consumes the TH AST will want the `TH.Name`s to have the right namespaces. It's really a bug that the fixity declaration above refers to a data constructor `Foo`. Going to implement (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 20:10:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 20:10:12 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.9259b873cae3802a74280808788024e3@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Well, option (2) is infeasible. This is because desugaring a quoted fixity declaration produces `TH.Name`s that do ''not'' have namespace information attached. This is a consequence of the fact that namespace information is available only with `TH.Name`'s `NameG` constructor, which also has package and module information. Of course, when processing a quote, we have no idea what package/module the declaration will eventually end up in, so `NameG` is a non-starter. Thus, we have no namespace information here, and instead must be liberal when processing `Exact` `RdrName`s. I suppose the Right Way to fix this is to add namespace information to TH's `NameU` and `NameL` constructors, but that probably has farther- reaching implications than need to be dealt with at this moment. Going to implement (1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 20:24:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 20:24:39 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.403ab98b89a4e749ad9cbb933d60c69d@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by merijn): * owner: => merijn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 20:24:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 20:24:54 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.a7b36605fda5cd95d7898abfb11b02f0@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by merijn): I'll try and see if I can hack this together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 20:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 20:50:24 -0000 Subject: [GHC] #9754: Fix Applicative instances in the wake of AMP Message-ID: <045.90711301dc726fa801461206d037a793@haskell.org> #9754: Fix Applicative instances in the wake of AMP -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: AMP | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I haven't tracked down all the problems yet, but several experiments leading to validation failures strongly suggest that some `Applicative` instances in the GHC tree fail to interact properly with their associated `Monad` instances. That is, `ap ? (<*>)` and/or `(>>) ? (*>)`. We should be able to fix these up by fleshing out the appropriate instance declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 22:50:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 22:50:51 -0000 Subject: [GHC] #9712: package "primitive" fails to install under msys2-i686 (Windows) In-Reply-To: <045.44b3a2c6a330919c7f9b94f8f0acc95b@haskell.org> References: <045.44b3a2c6a330919c7f9b94f8f0acc95b@haskell.org> Message-ID: <060.3209c24c70388cab81619f7cd87a7252@haskell.org> #9712: package "primitive" fails to install under msys2-i686 (Windows) ---------------------------------------+--------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------- Description changed by gintas: Old description: > If you follow the instructions for a 32-bit installation at > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows, > installation of alex fails. Not sure if this is an issue with alex or > with the environment. Transcript: > > $ cabal install alex > Resolving dependencies... > Downloading primitive-0.5.4.0... > Configuring primitive-0.5.4.0... > Failed to install primitive-0.5.4.0 > Build log ( > C:\Users\Gintas\AppData\Roaming\cabal\logs\primitive-0.5.4.0.log ): > [1 of 1] Compiling Main ( > C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.hs, > C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\Main.o > ) > Linking > C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.exe > ... > Configuring primitive-0.5.4.0... > setup-Simple-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe: Missing > dependency on > a foreign library: > * Missing (or bad) header file: primitive-memops.h > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library > is > already installed but in a non-standard location then you can use the > flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > If the header file does exist, it may contain errors that are caught by > the C > compiler at the preprocessing stage. In this case you can re-run > configure > with the verbosity flag -v3 to see the error messages. > > The primitive-memops.h file seems to be part of "primitive" itself. > > Passing in -v3 does not print anything interesting. > > $ cabal --version > cabal-install version 1.20.0.3 > using version 1.20.0.1 of the Cabal library > > $ cabal get primitive && cd primitive-* && cabal configure && cabal build > Unpacking to primitive-0.5.4.0\ > Resolving dependencies... > Configuring primitive-0.5.4.0... > Building primitive-0.5.4.0... > Preprocessing library primitive-0.5.4.0... > [ 1 of 10] Compiling Data.Primitive.Internal.Compat ( > Data\Primitive\Internal\Compat.hs, > dist\build\Data\Primitive\Internal\Compat.o ) > [ 2 of 10] Compiling Data.Primitive.MachDeps ( > Data\Primitive\MachDeps.hs, dist\build\Data\Primitive\MachDeps.o ) > [ 3 of 10] Compiling Data.Primitive.Internal.Operations ( > Data\Primitive\Internal\Operations.hs, > dist\build\Data\Primitive\Internal\Operations.o ) > [ 4 of 10] Compiling Control.Monad.Primitive ( > Control\Monad\Primitive.hs, dist\build\Control\Monad\Primitive.o ) > [ 5 of 10] Compiling Data.Primitive.Types ( Data\Primitive\Types.hs, > dist\build\Data\Primitive\Types.o ) > [ 6 of 10] Compiling Data.Primitive.Array ( Data\Primitive\Array.hs, > dist\build\Data\Primitive\Array.o ) > > Data\Primitive\Array.hs:32:1: Warning: > The import of `Control.Monad.ST' is redundant > except perhaps to import instances from `Control.Monad.ST' > To import instances alone, use: import Control.Monad.ST() > [ 7 of 10] Compiling Data.Primitive.ByteArray ( > Data\Primitive\ByteArray.hs, dist\build\Data\Primitive\ByteArray.o ) > [ 8 of 10] Compiling Data.Primitive.Addr ( Data\Primitive\Addr.hs, > dist\build\Data\Primitive\Addr.o ) > [ 9 of 10] Compiling Data.Primitive ( Data\Primitive.hs, > dist\build\Data\Primitive.o ) > [10 of 10] Compiling Data.Primitive.MutVar ( Data\Primitive\MutVar.hs, > dist\build\Data\Primitive\MutVar.o ) > In-place registering primitive-0.5.4.0... > > Any idea what's missing here? New description: If you follow the instructions for a 32-bit installation at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows, installation of alex fails. Not sure if this is an issue with alex or with the environment. Transcript: {{{ $ cabal install alex Resolving dependencies... Downloading primitive-0.5.4.0... Configuring primitive-0.5.4.0... Failed to install primitive-0.5.4.0 Build log ( C:\Users\Gintas\AppData\Roaming\cabal\logs\primitive-0.5.4.0.log ): [1 of 1] Compiling Main ( C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.hs, C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\Main.o ) Linking C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.exe ... Configuring primitive-0.5.4.0... setup-Simple-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe: Missing dependency on a foreign library: * Missing (or bad) header file: primitive-memops.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. If the header file does exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run configure with the verbosity flag -v3 to see the error messages. }}} The primitive-memops.h file seems to be part of "primitive" itself. Passing in -v3 does not print anything interesting. {{{ $ cabal --version cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal library $ cabal get primitive && cd primitive-* && cabal configure && cabal build Unpacking to primitive-0.5.4.0\ Resolving dependencies... Configuring primitive-0.5.4.0... Building primitive-0.5.4.0... Preprocessing library primitive-0.5.4.0... [ 1 of 10] Compiling Data.Primitive.Internal.Compat ( Data\Primitive\Internal\Compat.hs, dist\build\Data\Primitive\Internal\Compat.o ) [ 2 of 10] Compiling Data.Primitive.MachDeps ( Data\Primitive\MachDeps.hs, dist\build\Data\Primitive\MachDeps.o ) [ 3 of 10] Compiling Data.Primitive.Internal.Operations ( Data\Primitive\Internal\Operations.hs, dist\build\Data\Primitive\Internal\Operations.o ) [ 4 of 10] Compiling Control.Monad.Primitive ( Control\Monad\Primitive.hs, dist\build\Control\Monad\Primitive.o ) [ 5 of 10] Compiling Data.Primitive.Types ( Data\Primitive\Types.hs, dist\build\Data\Primitive\Types.o ) [ 6 of 10] Compiling Data.Primitive.Array ( Data\Primitive\Array.hs, dist\build\Data\Primitive\Array.o ) Data\Primitive\Array.hs:32:1: Warning: The import of `Control.Monad.ST' is redundant except perhaps to import instances from `Control.Monad.ST' To import instances alone, use: import Control.Monad.ST() [ 7 of 10] Compiling Data.Primitive.ByteArray ( Data\Primitive\ByteArray.hs, dist\build\Data\Primitive\ByteArray.o ) [ 8 of 10] Compiling Data.Primitive.Addr ( Data\Primitive\Addr.hs, dist\build\Data\Primitive\Addr.o ) [ 9 of 10] Compiling Data.Primitive ( Data\Primitive.hs, dist\build\Data\Primitive.o ) [10 of 10] Compiling Data.Primitive.MutVar ( Data\Primitive\MutVar.hs, dist\build\Data\Primitive\MutVar.o ) In-place registering primitive-0.5.4.0... }}} Any idea what's missing here? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 23:32:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 23:32:57 -0000 Subject: [GHC] #9685: GHC fails to build with mingw32-make on Windows In-Reply-To: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> References: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> Message-ID: <060.e22997a76e4f1f7d34f352ed9e9b415b@haskell.org> #9685: GHC fails to build with mingw32-make on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: feature | Status: new request | Milestone: Priority: low | Version: 7.9 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 23:33:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 23:33:22 -0000 Subject: [GHC] #9685: GHC fails to build with mingw32-make on Windows In-Reply-To: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> References: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> Message-ID: <060.cac86aa54d6dd38a92f9887c61d4f62d@haskell.org> #9685: GHC fails to build with mingw32-make on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: feature | Status: new request | Milestone: Priority: low | Version: 7.9 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): This is indeed due to command line truncation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 2 23:47:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Nov 2014 23:47:43 -0000 Subject: [GHC] #8571: Validation fails In-Reply-To: <047.033097cdeaab38530d03b9c092b94b8e@haskell.org> References: <047.033097cdeaab38530d03b9c092b94b8e@haskell.org> Message-ID: <062.8b907ac002823a0894f9f38c1e18396f@haskell.org> #8571: Validation fails ---------------------------------------+---------------------------------- Reporter: khyperia | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by gintas): * status: new => closed * resolution: => worksforme Comment: This is strange. The bug is oldish and no one else seems to have run into this problem, so I'll close it for now, but please reopen if this occurs again. What environment were you using to run the tests? It looks like it is tee that's complaining, so I'd wager the environment (cygwin/msys) is at fault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 00:16:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 00:16:28 -0000 Subject: [GHC] #8482: Permission denied when copying file to current directory with copyFile In-Reply-To: <047.eb30ac461435747b2b71651c93090ef6@haskell.org> References: <047.eb30ac461435747b2b71651c93090ef6@haskell.org> Message-ID: <062.e01ce2e2397e493b1032aff29bd61fc1@haskell.org> #8482: Permission denied when copying file to current directory with copyFile -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.6.3 Libraries | Keywords: copyFile Resolution: | permission denied Operating System: Windows | Architecture: x86 Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * cc: core-libraries-committee@? (added) Comment: This seems to be a special case of the issue when the destination path is a directory without the filename, not a full path (consider "mv foo.txt a/foo.txt" vs "mv foo.txt a/"). I suspect the difference in behavior is due to Win32.moveFileEx behaving differently from Posix.rename in this situation, see http://hackage.haskell.org/package/directory-1.2.1.0/docs/src/System- Directory.html#renameFile The documentation says that the second operand must not be a directory, but the code does not check for that. Looks like a bug then. There's likely code relying on the buggy behavior, the fix could be a bit risky... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 00:16:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 00:16:40 -0000 Subject: [GHC] #8482: Permission denied when copying file to current directory with copyFile In-Reply-To: <047.eb30ac461435747b2b71651c93090ef6@haskell.org> References: <047.eb30ac461435747b2b71651c93090ef6@haskell.org> Message-ID: <062.6e713cf96839f265c362626c2164278d@haskell.org> #8482: Permission denied when copying file to current directory with copyFile -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.6.3 Libraries | Keywords: copyFile Resolution: | permission denied Operating System: Windows | Architecture: x86 Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * owner: ekmett => gintas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 01:01:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 01:01:06 -0000 Subject: [GHC] #8687: Strange closure type 9983 In-Reply-To: <042.e67240730f3538eb274d4089a3c1c88e@haskell.org> References: <042.e67240730f3538eb274d4089a3c1c88e@haskell.org> Message-ID: <057.184bf1280e45dab32d03c01e3689d35a@haskell.org> #8687: Strange closure type 9983 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * os: Windows => Unknown/Multiple Comment: This does not look like it's windows specific, setting OS to generic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 01:02:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 01:02:09 -0000 Subject: [GHC] #8342: System.Directory.getPermissions does not work well on Windows 7 In-Reply-To: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> References: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> Message-ID: <060.6840f4cf792166002f2ee4fb204f3b65@haskell.org> #8342: System.Directory.getPermissions does not work well on Windows 7 -------------------------------------+------------------------------------- Reporter: freizl | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * cc: core-libraries-committee@? (added) Comment: How about being strict and always disallowing slashes at the end? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 01:03:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 01:03:37 -0000 Subject: [GHC] #8295: T4850 deadlocks when run with -Ds on Windows (also it's failing) In-Reply-To: <045.ea8855cfbb0ca611867f006360914806@haskell.org> References: <045.ea8855cfbb0ca611867f006360914806@haskell.org> Message-ID: <060.c0064695d1453f0e950402ec83f226b2@haskell.org> #8295: T4850 deadlocks when run with -Ds on Windows (also it's failing) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: worksforme | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: T4850 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * cc: simonmar (added) * status: new => closed * resolution: => worksforme Comment: Obsolete? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 01:11:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 01:11:44 -0000 Subject: [GHC] #8261: Windows Testsuite stuck at configuring timeout In-Reply-To: <045.30d4071afabba05509a3c315a3a1205c@haskell.org> References: <045.30d4071afabba05509a3c315a3a1205c@haskell.org> Message-ID: <060.b3aff5614e1eac32b1d15d03c56b6638@haskell.org> #8261: Windows Testsuite stuck at configuring timeout ---------------------------------------+--------------------------- Reporter: leroux | Owner: leroux Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------- Changes (by gintas): * status: new => closed * resolution: => worksforme Comment: This should not apply to our revamped Windows build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 01:16:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 01:16:54 -0000 Subject: [GHC] #989: Build GHC on Windows using Microsoft toolchain In-Reply-To: <047.96e16f269cc7176052a090de33c91146@haskell.org> References: <047.96e16f269cc7176052a090de33c91146@haskell.org> Message-ID: <062.bf490e09295762d2d2a5acb11a51427f@haskell.org> #989: Build GHC on Windows using Microsoft toolchain -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: feature | Status: new request | Milestone: ? Priority: low | Version: Component: Build | Keywords: System | Architecture: x86 Resolution: | Difficulty: Project (more Operating System: Windows | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 01:17:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 01:17:29 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.6c0fcaf99b076f2c8b889151cc68e6a5@haskell.org> #9246: GHC generates poor code for repeated uses of min/max -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #6135 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 01:18:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 01:18:27 -0000 Subject: [GHC] #8830: internal error: Misaligned section: 18206e5b on Windows In-Reply-To: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> References: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> Message-ID: <062.17f3b5de5f60ce699ca91fd29fe059e1@haskell.org> #8830: internal error: Misaligned section: 18206e5b on Windows -------------------------------------+------------------------------ Reporter: joeyhess | Owner: Type: bug | Status: infoneeded Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------ Changes (by gintas): * priority: normal => lowest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 01:23:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 01:23:06 -0000 Subject: [GHC] #9754: Fix Applicative instances in the wake of AMP In-Reply-To: <045.90711301dc726fa801461206d037a793@haskell.org> References: <045.90711301dc726fa801461206d037a793@haskell.org> Message-ID: <060.1474f450101c7058032758c2630a2103@haskell.org> #9754: Fix Applicative instances in the wake of AMP -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: AMP Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid Comment: Whoops! It looks like I picked the wrong suspect. Sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 01:23:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 01:23:14 -0000 Subject: [GHC] #110: Cygwin binaries In-Reply-To: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> References: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> Message-ID: <061.fe489b61982a542bb4fc8da983755a12@haskell.org> #110: Cygwin binaries -------------------------------------+------------------------------------- Reporter: fizzgig | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: None Component: None | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * priority: normal => lowest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 02:09:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 02:09:19 -0000 Subject: [GHC] #8342: System.Directory.getPermissions does not work well on Windows 7 In-Reply-To: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> References: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> Message-ID: <060.9a4ee50f7efceb2c80af3189ff021d8e@haskell.org> #8342: System.Directory.getPermissions does not work well on Windows 7 -------------------------------------+------------------------------------- Reporter: freizl | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by freizl): I think library user just like it works well without error or meaningful error. "Does not exists" make little sense IMHO. Being strict is good idea and I suppose core library would do either of below when has slash at the end - Fixed it auto hence getPermissions show result correctly. - Display errors like "shall no have slash at the end" Suggestions/comments? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 03:44:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 03:44:00 -0000 Subject: [GHC] #9202: Strange Closure Type In-Reply-To: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> References: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> Message-ID: <064.43d84cb40800c13532678d906c142cc2@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strange-closure- Operating System: Linux | type Type of failure: Compile- | Architecture: x86_64 (amd64) time crash | Difficulty: Project (more Test Case: | than a week) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): At the very least it does seem to still exist with 7.8.3: https://github.com/yi-editor/yi/issues/664 Sorry that I don't have any specific info for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 04:34:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 04:34:47 -0000 Subject: [GHC] #9011: panic - interactiveUI:setBuffering2 In-Reply-To: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> References: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> Message-ID: <059.81ddf128faa2327e420824c8cc890819@haskell.org> #9011: panic - interactiveUI:setBuffering2 -------------------------------------+---------------------------------- Reporter: irneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Comment (by gnezdo): I just hit the same problem when I had years worth of leftovers in /usr/local/lib/ghc on OpenBSD 5.6 amd64 with ghc-7.6.3. In particular, base package was probably messed up (as I surmise from complaints by cabal about base-loghexadecimal). This suggests this bug is a different manifestation of #7692. The workaround for me was to uninstall ghc package, remove everything under /usr/local/lib/ghc and reinstall again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 05:11:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 05:11:17 -0000 Subject: [GHC] #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl Message-ID: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE BangPatterns #-} import Data.Vector (Vector, (!)) import qualified Data.Vector as Vec import Data.Ix (Ix) import qualified Data.Ix as Ix vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a vecIndexIx vec ix = vec ! Ix.index (minBound :: ix, maxBound :: ix) ix vecCreateIx :: (Ix ix, Bounded ix) => (ix -> a) -> Vector a vecCreateIx f = Vec.fromListN (Ix.rangeSize bounds) [ y | ix <- Ix.range bounds, let !y = f ix ] where bounds = (minBound, maxBound) }}} The following errors occur: {{{ 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> :l cabal cabal.sandbox.config cabal_problem.hs Prelude> :l cabal_problem.hs [1 of 1] Compiling Main ( cabal_problem.hs, interpreted ) cabal_problem.hs:9:37: Could not deduce (Bounded ix1) arising from a use of ?minBound? from the context (Ix ix, Bounded ix) bound by the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a at cabal_problem.hs:8:16-57 Possible fix: add (Bounded ix1) to the context of an expression type signature: ix1 or the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a In the expression: minBound :: ix In the first argument of ?Ix.index?, namely ?(minBound :: ix, maxBound :: ix)? In the second argument of ?(!)?, namely ?Ix.index (minBound :: ix, maxBound :: ix) ix? cabal_problem.hs:9:53: Could not deduce (Bounded ix1) arising from a use of ?maxBound? from the context (Ix ix, Bounded ix) bound by the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a at cabal_problem.hs:8:16-57 Possible fix: add (Bounded ix1) to the context of an expression type signature: ix1 or the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a In the expression: maxBound :: ix In the first argument of ?Ix.index?, namely ?(minBound :: ix, maxBound :: ix)? In the second argument of ?(!)?, namely ?Ix.index (minBound :: ix, maxBound :: ix) ix? cabal_problem.hs:12:32: Could not deduce (Ix a0) arising from a use of ?Ix.rangeSize? from the context (Ix ix, Bounded ix) bound by the type signature for vecCreateIx :: (Ix ix, Bounded ix) => (ix -> a) -> Vector a at cabal_problem.hs:11:16-59 The type variable ?a0? is ambiguous Note: there are several potential instances: instance Ix () -- Defined in ?GHC.Arr? instance (Ix a, Ix b) => Ix (a, b) -- Defined in ?GHC.Arr? instance (Ix a1, Ix a2, Ix a3) => Ix (a1, a2, a3) -- Defined in ?GHC.Arr? ...plus 8 others In the first argument of ?Vec.fromListN?, namely ?(Ix.rangeSize bounds)? In the expression: Vec.fromListN (Ix.rangeSize bounds) [y | ix <- Ix.range bounds, let !y = f ix] In an equation for ?vecCreateIx?: vecCreateIx f = Vec.fromListN (Ix.rangeSize bounds) [y | ix <- Ix.range bounds, let !y = f ix] where bounds = (minBound, maxBound) cabal_problem.hs:12:45: Could not deduce (Bounded a0) arising from a use of ?bounds? from the context (Ix ix, Bounded ix) bound by the type signature for vecCreateIx :: (Ix ix, Bounded ix) => (ix -> a) -> Vector a at cabal_problem.hs:11:16-59 The type variable ?a0? is ambiguous Note: there are several potential instances: instance Bounded Data.Monoid.All -- Defined in ?Data.Monoid? instance Bounded Data.Monoid.Any -- Defined in ?Data.Monoid? instance Bounded a => Bounded (Data.Monoid.Dual a) -- Defined in ?Data.Monoid? ...plus 23 others In the first argument of ?Ix.rangeSize?, namely ?bounds? In the first argument of ?Vec.fromListN?, namely ?(Ix.rangeSize bounds)? In the expression: Vec.fromListN (Ix.rangeSize bounds) [y | ix <- Ix.range bounds, let !y = f ix] Failed, modules loaded: none. }}} The remedy was in this pull request https://github.com/haskell/hackage- server/pull/273/files under the file "Distribution/Server/Features/Search/DocTermIds.hs" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 05:50:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 05:50:06 -0000 Subject: [GHC] #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl In-Reply-To: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> References: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> Message-ID: <063.2b9e847c61400c982d669c2eafdf0bec@haskell.org> #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Do you have a `.ghci` file with `:set -XNoMonomorphismRestriction` by any chance? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 05:53:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 05:53:21 -0000 Subject: [GHC] #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl In-Reply-To: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> References: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> Message-ID: <063.415df11ad5bdc13e1a39702019d5aa4d@haskell.org> #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bitemyapp): @rwbarton - yes. Should this code never work without the monomorphism restriction enabled? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 06:04:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 06:04:04 -0000 Subject: [GHC] #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl In-Reply-To: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> References: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> Message-ID: <063.47750c2d9f12eb6afeae1784f748d15b@haskell.org> #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): This code relies on the monomorphism restriction since if `bounds` is generalized, there is nothing determining its type at its use in the subexpression `(Ix.rangeSize bounds)`. What might be confusing is that `:set -XFoo` affects the language extensions used when ''loading'' files in ghci. You probably want to use `:seti` in your `.ghci` file, which affects the language extensions used when evaluating expressions interactively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 06:39:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 06:39:52 -0000 Subject: [GHC] #8482: Permission denied when copying file to current directory with copyFile In-Reply-To: <047.eb30ac461435747b2b71651c93090ef6@haskell.org> References: <047.eb30ac461435747b2b71651c93090ef6@haskell.org> Message-ID: <062.795bc60680d5e1fde2c95a5a7c4eb4b0@haskell.org> #8482: Permission denied when copying file to current directory with copyFile -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.6.3 Libraries | Keywords: copyFile Resolution: | permission denied Operating System: Windows | Architecture: x86 Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): If this turns out to be a bug in `directory`, please file an issue at upstream https://github.com/haskell/directory/issues and change this ticket's state to "Upstream" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 06:41:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 06:41:28 -0000 Subject: [GHC] #8342: System.Directory.getPermissions does not work well on Windows 7 In-Reply-To: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> References: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> Message-ID: <060.20b31f28ed2789889c17ea0c8b23412e@haskell.org> #8342: System.Directory.getPermissions does not work well on Windows 7 -------------------------------------+------------------------------------- Reporter: freizl | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): If this turns out to be an issue in `directory`, please file an issue at upstream https://github.com/haskell/directory/issues and change this ticket's state to "Upstream" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 07:03:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 07:03:24 -0000 Subject: [GHC] #9756: Warn about unnecessary unsafeCoerce Message-ID: <045.5b6c1cb850fc12c4b8f4fd479d405f05@haskell.org> #9756: Warn about unnecessary unsafeCoerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `unsafeCoerce` has been around a lot longer than `coerce`, so older code tends to use it even if `coerce` could do the job. It would be nice if the type checker could produce a warning when it detected such a situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 07:14:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 07:14:04 -0000 Subject: [GHC] #9757: Warn about derivable instances Message-ID: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC can derive a lot of instances by itself, and can sometimes (with `GeneralizedNewtypeDeriving`) do so better than anyone else. I'd like to be able to get a warning about any instance that's "obviously equivalent" to the one that would be derived, for some suitable values of "obviously" and "equivalent". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 07:57:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 07:57:04 -0000 Subject: [GHC] #110: Cygwin binaries In-Reply-To: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> References: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> Message-ID: <061.32df23effe318758dbf974ec353c4034@haskell.org> #110: Cygwin binaries -------------------------------------+------------------------------------- Reporter: fizzgig | Owner: Type: feature | Status: closed request | Milestone: ? Priority: lowest | Version: None Component: None | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: None => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 08:19:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 08:19:38 -0000 Subject: [GHC] #9712: package "primitive" fails to install under msys2-i686 (Windows) In-Reply-To: <045.44b3a2c6a330919c7f9b94f8f0acc95b@haskell.org> References: <045.44b3a2c6a330919c7f9b94f8f0acc95b@haskell.org> Message-ID: <060.f518f58f9ca19344220b8fca9967e138@haskell.org> #9712: package "primitive" fails to install under msys2-i686 (Windows) ---------------------------------------+--------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------- Comment (by awson): I could not reproduce this with cabal-1.20 official binary. I see you using cabal 1.18. Could you try to test if this is the case for cabal 1.20? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 09:28:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 09:28:30 -0000 Subject: [GHC] #9758: By default, testsuite should clean up after successful tests Message-ID: <045.6afbb9f1f5e466d1289d5bd3af0bb1ad@haskell.org> #9758: By default, testsuite should clean up after successful tests -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A fully built GHC compiler for development takes about 1G of space. However, running the testsuite balloons this amount to 10G. Why? Because we don't clear away any test files by default. Now, it's pretty useful to have these files if you're debugging a problem. But I think it's pretty unnecessary for successful tests. So I suggest cleaning out the files automatically if the test succeeds. Tradeoff: the testsuite will take longer to run since it is cleaning up after itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 11:20:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 11:20:13 -0000 Subject: [GHC] #9758: By default, testsuite should clean up after successful tests In-Reply-To: <045.6afbb9f1f5e466d1289d5bd3af0bb1ad@haskell.org> References: <045.6afbb9f1f5e466d1289d5bd3af0bb1ad@haskell.org> Message-ID: <060.93fceef35d846031e0e4726df51da71d@haskell.org> #9758: By default, testsuite should clean up after successful tests -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): I'm not sure what you mean... if you look at the top-level Makefile, the `test` targets (which are also used by `./validate`) already cleanup by default: {{{#!make .PHONY: test test: $(MAKE) -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt fast .PHONY: fulltest fulltest: $(MAKE) -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 12:57:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 12:57:39 -0000 Subject: [GHC] #9755: Unhelpful error message when -XScopedTypeVariables is omitted (was: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl) In-Reply-To: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> References: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> Message-ID: <063.40e6d788d8a96524f968e5ea8f0f108c@haskell.org> #9755: Unhelpful error message when -XScopedTypeVariables is omitted -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I believe that the real problem is that in the definition of {{{ vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a vecIndexIx vec ix = vec ! Ix.index (minBound :: ix, maxBound :: ix) ix }}} you probably think that the uses of `ix` in the RHS mean the same `ix` as in the type signature. To achieve that you need `-XScopedTypeVariables` and an explicit `forall`: {{{ vecIndexIx :: forall a ix. (Ix ix, Bounded ix) => Vector a -> ix -> a vecIndexIx vec ix = vec ! Ix.index (minBound :: ix, maxBound :: ix) ix }}} Now it works fine. What you wrote is equivalent to {{{ vecIndexIx vec ix = vec ! Ix.index (minBound :: forall ix. ix, maxBound :: forall ix. ix) ix }}} where the type signature `blah :: ix` is universally quantified to `blah :: forall ix. ix`. It's an easy mistake to make. It might be a good idea if GHC spotted type variables that have the same name as one belonging to an enclosing, but un-scoped, type signature, and suggested this change. If someone wanted to try that, I could advise. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 13:23:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 13:23:44 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.69ba26d293773d5b7b8c19ce274c4a94@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D329 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 13:26:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 13:26:24 -0000 Subject: [GHC] #8849: Unregisterised compiler: arithmetic failure In-Reply-To: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> References: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> Message-ID: <062.716b7987900f30412f84fa59822e1989@haskell.org> #8849: Unregisterised compiler: arithmetic failure -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: arith005 | Blocked By: Blocking: 8819 | Related Tickets: #8819 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: These have been merged into `ghc-7.8`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 13:26:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 13:26:42 -0000 Subject: [GHC] #8819: 64bit Testsuite failures in unregisterised 7.8 RCs In-Reply-To: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> References: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> Message-ID: <062.200423d6b53a01536e9604f33d3a3e48@haskell.org> #8819: 64bit Testsuite failures in unregisterised 7.8 RCs -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: 8849, 8933 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: I was able to merge all these cleanly except eb64be7b40b7f29144ebbf9c947e729535a8fd3d and e1d77a1ae619efc4bfe7ce30d7c6b2031ed86f2f, but I think that's OK. All the core fixes were merged, thanks Sergei! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 13:41:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 13:41:51 -0000 Subject: [GHC] #9658: Prettyprint constraints in type signatures can omit necessary parentheses In-Reply-To: <051.729c40b7d3b349724f12a1d337527b9b@haskell.org> References: <051.729c40b7d3b349724f12a1d337527b9b@haskell.org> Message-ID: <066.416515f0d815e291db2b1e4abf5e956a@haskell.org> #9658: Prettyprint constraints in type signatures can omit necessary parentheses -------------------------------------+------------------------------------- Reporter: | Owner: Blaisorblade | Status: closed Type: bug | Milestone: 7.8.4 Priority: low | Version: 7.8.3 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: ghci/scripts/T9658 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to `ghc-7.8`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 13:42:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 13:42:16 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 In-Reply-To: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> References: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> Message-ID: <065.4fa78edf6a987e09a11d911c555c4896@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 -------------------------------------+------------------------------------- Reporter: | Owner: MichalGajda | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #7068, #7898 time crash | Test Case: cabal | install hPDB | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to `ghc-7.8`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 13:45:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 13:45:19 -0000 Subject: [GHC] #8342: System.Directory.getPermissions does not work well on Windows 7 In-Reply-To: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> References: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> Message-ID: <060.6d6e7e5e366ee001db1f7dc211a532ec@haskell.org> #8342: System.Directory.getPermissions does not work well on Windows 7 -------------------------------------+------------------------------------- Reporter: freizl | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): I'd think we'd want `directory` to just do the right thing and normalize before handing it off to the OS on windows. All the other platforms deal gracefully with trailing slashes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 13:45:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 13:45:21 -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.20d736919e7ec416038ee462d055b1b0@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 | Version: 7.8.2 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: core-libraries-committee@? (added) * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.8`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 13:47:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 13:47:09 -0000 Subject: [GHC] #9705: Panic on a pattern synonym in a class In-Reply-To: <047.614ec39c173b8238a9064e76b118d842@haskell.org> References: <047.614ec39c173b8238a9064e76b118d842@haskell.org> Message-ID: <062.0b6d97aabb263518fd80f288dbffb22c@haskell.org> #9705: Panic on a pattern synonym in a class -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: pattern synonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.4 Comment: Merged to `ghc-7.8`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 13:47:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 13:47:30 -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.35f395bb3e75b6b32bc6102572f1ded3@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 | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #8634 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: invalid => Comment: Yes, I'll re-open it. But lacking someone who cares about functional dependencies, it's a bit in limbo. Fundep enthusiasts, stand forth! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 14:05:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 14:05:51 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.beb9eef07677355b8208a9155537fc2b@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm a bit confused. * What does the TH syntax look like? Presumably `InfixD fixity name` where `name :: TH.Name`. * What is the flavour of that `name`? Presumably not a `NameG`? So `NameS` or `NameL`? * If `NameS`, we never generate an `Exact` `RdrName`, so I guess `NameL`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 14:20:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 14:20:00 -0000 Subject: [GHC] #9433: Partially applied type family allowed but unusable In-Reply-To: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> References: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> Message-ID: <063.dc797595e3a9c7b4b27df0d339d18b41@haskell.org> #9433: Partially applied type family allowed but unusable -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: indexed- | types/should_fail/T9433 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.4 Comment: Merged to `ghc-7.8`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 14:22:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 14:22:45 -0000 Subject: [GHC] #9633: PolyKinds in 7.8.2 vs 7.8.3 In-Reply-To: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> References: <047.b86bfcf16093ced96c31b71da64efba9@haskell.org> Message-ID: <062.b115dd422b4d4385fd72c4c78a4da114@haskell.org> #9633: PolyKinds in 7.8.2 vs 7.8.3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.1 Comment: This won't be changing for 7.8, but will be in 7.10. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 14:25:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 14:25:26 -0000 Subject: [GHC] #9759: Add Alternative wrapper to Data.Monoid Message-ID: <045.9ddae74098f5edc53dc82839cb308d90@haskell.org> #9759: Add Alternative wrapper to Data.Monoid -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As discussed on the libraries list, {{{#!hs -- | Monoid under @<|>@. newtype Alt f a = Alt {getAlt :: f a} deriving (Generic, Generic1, Read, Show, Eq, Ord, Num, Enum, Monad, MonadPlus, Applicative, Alternative, Functor) instance forall f a . Alternative f => Monoid (Alt f a) where mempty = Alt empty mappend = coerce ((<|>) :: f a -> f a -> f a) }}} The documentation for `Data.Monoid.First` and `Data.Monoid.Last` should also be expanded to explain that `First a` is isomorphic to `Alt Maybe a` and `Last a` is isomorphic to `Dual (Alt Maybe a)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 14:29:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 14:29:16 -0000 Subject: [GHC] #9359: Deriving clause failure with polymorphic kinds In-Reply-To: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> References: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> Message-ID: <061.ae7a3bc953e7e1771a64852e7ae19175@haskell.org> #9359: Deriving clause failure with polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T9359 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.1 Comment: This one is a bit tricky to merge due to several other major changes touching `TcDeriv.lhs`, so I'm afraid this one will be left out of 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 14:45:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 14:45:21 -0000 Subject: [GHC] #9756: Warn about unnecessary unsafeCoerce In-Reply-To: <045.5b6c1cb850fc12c4b8f4fd479d405f05@haskell.org> References: <045.5b6c1cb850fc12c4b8f4fd479d405f05@haskell.org> Message-ID: <060.94c91682e041dd128292f161ab8c1db4@haskell.org> #9756: Warn about unnecessary unsafeCoerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm intrigued by this idea. But, it would surely have a performance impact, if extra analysis must be done on every use of `unsafeCoerce`. Would this be opt-in? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 14:47:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 14:47:36 -0000 Subject: [GHC] #9757: Warn about derivable instances In-Reply-To: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> References: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> Message-ID: <060.c70b70bba88e4dab776d227680e90556@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): To my knowledge, GHC can ''not'' derive instances better than anyone else. Since the advent of `coerce`, `GeneralizedNewtypeDeriving` has no magic -- any GND instance can be written by hand, sometimes with lots of type annotations and `ScopedTypeVariables`, though. Personally, I would want to see nice definitions of "obviously" and "equivalent" before thinking too much harder about this. This seems hard to do and not terribly useful, to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 14:51:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 14:51:57 -0000 Subject: [GHC] #8443: cannot find normal object file when compiling TH code In-Reply-To: <047.2f61f8c2ce8e4b4c9fecbd7d2a24e60d@haskell.org> References: <047.2f61f8c2ce8e4b4c9fecbd7d2a24e60d@haskell.org> Message-ID: <062.3801969693ec7269c7853cfa43decae1@haskell.org> #8443: cannot find normal object file when compiling TH code -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): For readers who pass by: `other-extensions: TemplateHaskell` in your cabal file is the recommended way to deal with this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 15:10:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 15:10:51 -0000 Subject: [GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot Message-ID: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I discovered that if I compile with `ghc -c -osuf .something Myfile.hs` where `Myfile.hs` contains TH and thus has to dynamically link in, say, `Other.hs`, I get the error that {{{ Myfile.hs:1:1: cannot find normal object file 'Othe.dyn_o` while linking an interpreted expression }}} So `Other` was wrongly made into `Othe`, dropping the last character. If I don't pass `-osuf .something`, or have it not have a dot, everything's fine. The trouble is that `-osuf .something` worked fine in GHC <= 7.6. So I believe this is a regression, or at least a very bad error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 15:14:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 15:14:32 -0000 Subject: [GHC] #9756: Warn about unnecessary unsafeCoerce In-Reply-To: <045.5b6c1cb850fc12c4b8f4fd479d405f05@haskell.org> References: <045.5b6c1cb850fc12c4b8f4fd479d405f05@haskell.org> Message-ID: <060.e362cf5c89865cc138f332b09309f50c@haskell.org> #9756: Warn about unnecessary unsafeCoerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I would tend to think it should be opt-in anyways, at least for a couple compiler versions, since it would just annoy people who want to support those older compiler versions without `coerce`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 15:22:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 15:22:59 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.15be9933587f8a207c6b5e996598a02f@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: #5550 #8852 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * version: 7.6.3 => 7.9 * os: MacOS X => Unknown/Multiple * related: 5550 => #5550 #8852 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 15:34:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 15:34:00 -0000 Subject: [GHC] #9757: Warn about derivable instances In-Reply-To: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> References: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> Message-ID: <060.88cff9f15231de7bf3fe3f5362d82468@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 goldfire]: > To my knowledge, GHC can ''not'' derive instances better than anyone else. Since the advent of `coerce`, `GeneralizedNewtypeDeriving` has no magic -- any GND instance can be written by hand, sometimes with lots of type annotations and `ScopedTypeVariables`, though. I don't ''think'' this is exactly right. As I understand it, `coerce` should let you hand-build an exact ''copy'' of an existing dictionary, but `GeneralizedNewtypeDeriving` lets you actually ''reuse'' the dictionary. > Personally, I would want to see nice definitions of "obviously" and "equivalent" before thinking too much harder about this. This seems hard to do and not terribly useful, to me. It's useful because GHC can derive a lot more things today than in olden times, and there's a lot of old code that hasn't noticed yet. The notion of "obviously" is to recognize plain wrap/unwrap patterns, preferably with enough flexibility to handle both pattern-matching versions and `(.)` versions and maybe even a little inlining. The scare quotes around "equivalent" were to recognize the potential for arity mismatches?a hand- written version may guarantee a certain arity that the GND-derived version does not. {{{#!hs newtype Foo m = Foo m instance Monoid m => Monoid Foo m where mempty = Foo mempty Foo x `mappend` Foo y = Foo (x `mappend` y) }}} I'd want this to be recognized as derivable even though it guarantees that `mappend _|_ = const _|_ /= _|_` while the GND-derived instance would not make such a guarantee. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 15:43:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 15:43:03 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.f93a77188f97ec40c5ce404bf713f84e@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): This sample program was educational for me: {{{ import Language.Haskell.TH.Syntax import GHC.Exts ( Int(I#) ) import Data.Generics ( listify ) $( do let getNames = listify (const True :: Name -> Bool) showNS VarName = "VarName" showNS DataName = "DataName" showNS TcClsName = "TcClsName" showFlav NameS = "NameS" showFlav (NameQ mod) = "NameQ " ++ show mod showFlav (NameU i) = "NameU " ++ show (I# i) showFlav (NameL i) = "NameL " ++ show (I# i) showFlav (NameG ns pkg mod) = "NameG " ++ showNS ns ++ " " ++ show pkg ++ " " ++ show mod toString (Name occ flav) = show occ ++ " (" ++ showFlav flav ++ ")" decs <- [d| type Foo a b = Either a b infix 5 `Foo` data Blargh = Foo |] runIO $ do putStr $ unlines $ map show decs putStrLn "" putStr $ unlines $ map toString $ getNames decs return [] ) }}} The goal here is to learn more about the `Name`s used in the desugaring. Here is my output: {{{ TySynD Foo_1627434972 [PlainTV a_1627434975,PlainTV b_1627434976] (AppT (AppT (ConT Data.Either.Either) (VarT a_1627434975)) (VarT b_1627434976)) InfixD (Fixity 5 InfixN) Foo_1627434974 InfixD (Fixity 5 InfixN) Foo_1627434972 DataD [] Blargh_1627434973 [] [NormalC Foo_1627434974 []] [] OccName "Foo" (NameU 1627434972) OccName "a" (NameU 1627434975) OccName "b" (NameU 1627434976) OccName "Either" (NameG TcClsName PkgName "base" ModName "Data.Either") OccName "a" (NameU 1627434975) OccName "b" (NameU 1627434976) OccName "Foo" (NameU 1627434974) OccName "Foo" (NameU 1627434972) OccName "Blargh" (NameU 1627434973) OccName "Foo" (NameU 1627434974) }}} We see here a few things: - My solution (2) above is already somewhat implemented. Note that the quote has only '''1''' fixity declaration, but the desugared TH AST has '''2'''! This was the essence of my idea (2) above. - GHC correctly notices the difference between the type `Foo` and the data constructor `Foo` in a quote. - All of the local names are `NameU`s. These `NameU`s indeed become `Exact`s during splicing. But, the round trip from quote to TH AST to splice loses the namespace information, because `NameU`s do not carry namespace info. So, we either add namespace information to `NameU` or implement (1), above. Adding namespace info to `NameU` is slightly annoying, because fixity declarations are the ''only'' place that the namespace isn't apparent from a usage site. Another possible solution is to add namespace info to the `InfixD` TH constructor. This is dissatisfactory because TH should model concrete syntax, and concrete syntax doesn't have a namespace marker there. I'm happy to take suggestions, but my tendency is toward (1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 15:50:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 15:50:55 -0000 Subject: [GHC] #9757: Warn about derivable instances In-Reply-To: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> References: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> Message-ID: <060.6b7220c85575f7de2194faa0669bb900@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 dfeuer]: > Replying to [comment:1 goldfire]: > > To my knowledge, GHC can ''not'' derive instances better than anyone else. Since the advent of `coerce`, `GeneralizedNewtypeDeriving` has no magic -- any GND instance can be written by hand, sometimes with lots of type annotations and `ScopedTypeVariables`, though. > > I don't ''think'' this is exactly right. As I understand it, `coerce` should let you hand-build an exact ''copy'' of an existing dictionary, but `GeneralizedNewtypeDeriving` lets you actually ''reuse'' the dictionary. No, GND doesn't let you reuse dictionaries. Superclass instances might be different between the representation type and the newtype, and so reusing a dictionary might be wrong. GND builds a copy. (This surprised me, too, when I learned it.) > It's useful because GHC can derive a lot more things today than in olden times, and there's a lot of old code that hasn't noticed yet. I still think this would be quite a bit of work and one more thing to maintain within GHC. The feature would also necessarily be heuristic in nature. It strikes me this would make a great feature in HLint, but I personally don't think GHC is the right home for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:18:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:18:57 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.5d94bdf84e27ae4bfd3dfdc8958ff468@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun004 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: normal => highest * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:24:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:24:17 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.61582d873bcf93b0efd2771f99bea156@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D424 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D424 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:28:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:28:20 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.6d08818d94d19051015815008fce49d6@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Not GHCi specific, but my guess is that `-XTemplateHaskell` was not enabled in the standalone example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:31:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:31:08 -0000 Subject: [GHC] #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable Message-ID: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If GND is enabled, and roles don't permit a `Foldable` instance to be derived, it won't fall back on `DeriveFoldable`; instead it just produces an error. I think ideally I'd want to use a pragma to state explicitly that I want to use `DeriveFoldable`-style deriving for this specific instance, but an implicit fallback would be acceptable. {{{#!hs {-# LANGUAGE -- GeneralizedNewtypeDeriving, DeriveFoldable #-} module Derive where import qualified Data.IntMap as M newtype UniqFM ele = UFM {unUFM :: M.IntMap ele} deriving (Foldable) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:32:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:32:45 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.51b6cc6a0f1cc77cc89e4612353c6a88@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): `-funbox-strict-fields` is enabled with `-O` and `-O2`, which is not mentioned in 4.20 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:33:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:33:45 -0000 Subject: [GHC] #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable In-Reply-To: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> References: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> Message-ID: <060.2e4ee835be9126e5b1f29ec152221d1e@haskell.org> #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:45:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:45:59 -0000 Subject: [GHC] #9762: #8696 + #9012 Message-ID: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As of the patch for #9012, we create a static reference to an HPC ticks label if and only if it is in the same package, which is correct for building normally, but not for building libraries that are to be loaded piecemeal by GHCi/TH (as was the issue in #8696). See http://lpaste.net/113689 for an example error. I also wonder whether the other cases of `CLabel.labelDynamic` that check for "same package" could result in similar issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:50:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:50:04 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.5d57c5824f8e66d5a4698f0c69adffca@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2, niklash@?, aehlig@? (added) * related: => #8696, #9012 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:50:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:50:20 -0000 Subject: [GHC] #9757: Warn about derivable instances In-Reply-To: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> References: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> Message-ID: <060.c017bef52e8e70ed0b66b715ca7aab2e@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Thinking more about about this ticket and #9756, I think the purpose of compiler warnings should be to warn about code that is probably bad, not code that is probably fine that could be written in a (potentially) better way. (After all, we don't warn about excess parentheses in code either.) That is the domain of hlint, as Richard notes. Now #9756 is possibly an exception, if GHC is in a unique position to decide whether the replacement of `coerce` will type check, but I think the principle is a good one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:56:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:56:37 -0000 Subject: [GHC] #9762: #8696 + #9012 In-Reply-To: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> References: <047.1416552af7b7cba6e17e930c77b546df@haskell.org> Message-ID: <062.e15479609126871b9f037d1903bbda1d@haskell.org> #9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8696, #9012 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): Some discussion from #ghc for readers who'd like context: '''nh2''': thoughtpolice, '''rwbarton''': I am getting the "recompile with -fPIC" message in my `ghc -M` based setup, which you discussed in https://ghc.haskell.org/trac/ghc/ticket/8696. If I get this message, does it really mean that I need -fPIC or that I'm calling something wrong? '''rwbarton''': you probably don't want -fPIC specifically, but rather whichever one of -shared and -dynamic is the one you want '''rwbarton''': however, we can't know without more context '''rwbarton''': or possibly something is just broken :) '''nh2''': so, in the end I don't want any dynamic linking at all, but I understand it that I need some form of it for GHCI to load modules during TH evaluation, right? carter: yeah '''rwbarton''': yes carter: at least for onw carter: i think luite got his TH patch ready? '''nh2''': so I'm not sure which one of -shared and -dynamic I want for ghci to "just work" '''rwbarton''': you will need to build both ways '''nh2''': so I'm already compiling with -dynamic-too; in this case, what do I have to add? '''rwbarton''': well then we need to see a real error '''nh2''': http://lpaste.net/113689 '''rwbarton''': oh, and you are using hpc too '''rwbarton''': I thought I fixed this... '''rwbarton''': what version of ghc? '''rwbarton''': that should be fixed in 7.8.3 I think '''nh2''': 7.8.3, unfortunately '''rwbarton''': hm '''rwbarton''': oh, right '''rwbarton''': I knew about this when I fixed it :) '''rwbarton''': but I wrote the test in the same form as the surrounding code '''rwbarton''': hpc and TH won't interact well currently '''rwbarton''': I think you are one of 3 people to use HPC '''nh2''': we are a 4 person team '''nh2''': define "won't interact well" between [works if you disable it somehow for the libs loaded in ghci .... and .... you got no chance] :) '''rwbarton''': basically your bug is the bastard child of #9012 and #8696 '''rwbarton''': well if you could build the dynamic objects without HPC then it should work '''nh2''': do you reckon there is also a full solution to this? Also, is this now a bug, should I file one? '''rwbarton''': there's a bunch of trivial fixes to every individual problem of this form '''rwbarton''': each one also costs a little performance in the associated situation '''rwbarton''': I guess if you are building with hpc then you don't care about this level of overhead '''nh2''': is there a way to tell the -dynamic-too invocation that I don't want HPC only for the dynamic files? Or will I have to stop using -dynamic-too and create the dynamic ones manually to achieve that? '''rwbarton''': but really we should find a better way to deal with the underlying issue, since it does cost a measurable amount of performance on anything built dynamically '''rwbarton''': probably the latter -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:56:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:56:57 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.0d25a63bccb824384e0caf6d15e9e28e@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): While I'm at it, should I also allow "naked" expressions to be interpreted as splices in non-top-level contexts? I say "no", but am happy to hear others' opinions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 16:59:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 16:59:44 -0000 Subject: [GHC] #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable In-Reply-To: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> References: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> Message-ID: <060.fc54343976c3635bf333a3f2cf80d72d@haskell.org> #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * owner: => dfeuer * component: Compiler (Type checker) => Core Libraries Comment: Reid Barton thinks this is probably caused by the accidental redundant `Foldable` contexts on `Foldable` members. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:00:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:00:47 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.ea01e100738402f9155cc536f2ed235b@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Jan, you said you'd be willing to do this updating before 7.10 which would be excellent. So far as I can see, there simply is no list of what is enabled by -O or -O2. I'm not sure if there should be. It's more than a simple on/off thing because the order matters. Almost anything would be an improvement! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:02:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:02:26 -0000 Subject: [GHC] #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable In-Reply-To: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> References: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> Message-ID: <060.7fd7f39b6bc1b35620bc1f04b103ff6e@haskell.org> #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): (To clarify, "this" = the fact that Foldable's parameter has type role nominal in HEAD, preventing GND. In 7.8 it has role representational, as it should.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:04:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:04:12 -0000 Subject: [GHC] #9756: Warn about unnecessary unsafeCoerce In-Reply-To: <045.5b6c1cb850fc12c4b8f4fd479d405f05@haskell.org> References: <045.5b6c1cb850fc12c4b8f4fd479d405f05@haskell.org> Message-ID: <060.8a1b33f8c4520be3a56462cbbd95ca21@haskell.org> #9756: Warn about unnecessary unsafeCoerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): It's be a bit awkward to implement: it amounts to emitting a constraint, and then reporting a warning if the constraint ''can'' be solved, but nothing if it ''can't''. But I'm sure it's possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:05:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:05:10 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.6fe53fd16f29bd89294f9b730d0eaa49@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Merijn: thanks. FYI I think the 7.10 freeze will be mid-Nov. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:30:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:30:37 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.24773d56eab63efc9c437a8e5b513e7a@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I say "no". I rather doubt that it was a good decision to allow naked TH splices at top level! Let's not propagate it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:31:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:31:36 -0000 Subject: [GHC] #9757: Warn about derivable instances In-Reply-To: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> References: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> Message-ID: <060.88cd2f3e3ba3e6ed235e7dc3c421de01@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I rather agree with Reid here. I.e. won't-fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:51:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:51:43 -0000 Subject: [GHC] #9761: Foldable cannot be derived by GND due to redundant contexts (was: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable) In-Reply-To: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> References: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> Message-ID: <060.da99a90125c34940c46cda452f777725@haskell.org> #9761: Foldable cannot be derived by GND due to redundant contexts -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D425 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D425 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:53:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:53:22 -0000 Subject: [GHC] #9759: Add Alternative wrapper to Data.Monoid In-Reply-To: <045.9ddae74098f5edc53dc82839cb308d90@haskell.org> References: <045.9ddae74098f5edc53dc82839cb308d90@haskell.org> Message-ID: <060.b4e334d353be70529ab98630876e1fb4@haskell.org> #9759: Add Alternative wrapper to Data.Monoid -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D422 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D422 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:55:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:55:25 -0000 Subject: [GHC] #9742: The default definitions of foldl1 and foldr1 are too strict In-Reply-To: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> References: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> Message-ID: <060.b8d7aad68fe9e8e96a4364aa1b4ce578@haskell.org> #9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D423 | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: Phab:D416 => Phab:D423 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 17:56:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 17:56:58 -0000 Subject: [GHC] #9759: Add Alternative wrapper to Data.Monoid In-Reply-To: <045.9ddae74098f5edc53dc82839cb308d90@haskell.org> References: <045.9ddae74098f5edc53dc82839cb308d90@haskell.org> Message-ID: <060.58f347857e0e837bc8bc9c86bbdb7d02@haskell.org> #9759: Add Alternative wrapper to Data.Monoid -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D422 | -------------------------------------+------------------------------------- Comment (by dfeuer): Mailing list thread supporting addition: https://www.haskell.org/pipermail/libraries/2014-October/024045.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 18:11:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 18:11:00 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.13cad59cc008f1e7bda3ae67eabc9beb@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I tend to agree about the weirdness of naked top-level expressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 18:16:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 18:16:59 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.9382da8eac3c8ef01c73f4b8d1c15dd8@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Instead of implementing spliced declarations in more contexts, I'm just going to fix the panic and turn it into a sensible error message. In contrast to Simon's comment:2, not all the heavy lifting is done. To implement declaration splices in other contexts, it will be necessary to make rather drastic changes to the relevant AST nodes: we would need, say, an `HsLocalBinds` now to store declarations in the order they were written, so we can use declaration splices to break up mutually recursive blocks, as we do at top level. The same would have to be done for classes and instances. This would add up to quite a lot of code change, for a feature no one has actually requested. (I'm taking the original report to be a complaint about a panic, not a complaint about a missing splice feature.) All of this ''is'' possible, but it's more work than I wish to invest at the moment. Expect a patch soon fixing the error message, but if you want non-top-level declaration splices, please create a new ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 18:25:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 18:25:46 -0000 Subject: [GHC] #9761: Foldable cannot be derived by GND due to redundant contexts In-Reply-To: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> References: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> Message-ID: <060.1dd11e8d327870349ad6e6afc8567602@haskell.org> #9761: Foldable cannot be derived by GND due to redundant contexts -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D425 | -------------------------------------+------------------------------------- Comment (by goldfire): As Mr. Role, I agree with the analysis reported in comment:2. (But, just to be pedantic, I disagree with the phrasing in comment:3. `Foldable` should most certainly have a nominal role on its parameter, because we don't want to be able to coerce an existentially-bound `Foldable` dictionary, as `Foldable MyList` and `Foldable []` might be different. However, the extra `Foldable` constraints do cause GND to fail, because the constraint gets instantiated before coercing, and then it looks like we're trying to coerce `Foldable []` to `Foldable MyList`, which is bad.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 18:47:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 18:47:56 -0000 Subject: [GHC] #9763: Implement Foldable methods for Array directly Message-ID: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> #9763: Implement Foldable methods for Array directly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, they're implemented via conversion to lists. This works out sanely for `foldr` and `foldr1`, after some transformations, but it's rather less sane for left folds. Left folds end up "twisted" like their list counterparts, giving potentially surprising performance characteristics. For `Array`, left and right folds can reasonably be expected to be symmetrical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 18:52:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 18:52:17 -0000 Subject: [GHC] #9763: Implement Foldable methods for Array directly In-Reply-To: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> References: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> Message-ID: <060.ab362af9c2638543cdd31bae8a38c27c@haskell.org> #9763: Implement Foldable methods for Array directly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D428 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D428 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 18:53:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 18:53:19 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.04af93e0e4b47494531a04fa987fc69b@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D429 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D429 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 19:07:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 19:07:54 -0000 Subject: [GHC] #9081: Template Haskell gets confused with scoped kind variables in a class declaration In-Reply-To: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> References: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> Message-ID: <062.1a6db6170164e7eb89dc647ff723be23@haskell.org> #9081: Template Haskell gets confused with scoped kind variables in a class declaration -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Not reproducible anymore, in HEAD or in 7.8.3. I guess it's fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 19:42:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 19:42:40 -0000 Subject: [GHC] #8482: Permission denied when copying file to current directory with copyFile In-Reply-To: <047.eb30ac461435747b2b71651c93090ef6@haskell.org> References: <047.eb30ac461435747b2b71651c93090ef6@haskell.org> Message-ID: <062.ac9cc42540d9e5616b02fef2d2f96662@haskell.org> #8482: Permission denied when copying file to current directory with copyFile -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: gintas Type: bug | Status: closed Priority: normal | Milestone: Component: Core | Version: 7.6.3 Libraries | Keywords: copyFile Resolution: wontfix | permission denied Operating System: Windows | Architecture: x86 Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => closed * resolution: => wontfix Comment: Actually, never mind, Posix.rename behaves the same as Win32.moveFileEx, both check themselves that the destination is not a directory. The only problem is that the error message is misleading in some cases ("Access denied" instead of "InappropriateType"). Otherwise, it's all working as intended... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 20:41:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 20:41:32 -0000 Subject: [GHC] #7484: Template Haskell allows building invalid record fields/names In-Reply-To: <045.397b38fee58f310a634c2d78baa84281@haskell.org> References: <045.397b38fee58f310a634c2d78baa84281@haskell.org> Message-ID: <060.b1c582b4c280017b4526de49c7c0523f@haskell.org> #7484: Template Haskell allows building invalid record fields/names -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D431 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D431 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 21:54:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 21:54:58 -0000 Subject: [GHC] #3376: hpc and CPP don't mix on Windows In-Reply-To: <044.6ac0df9e14fafd4394d0f7a94cb2ccc6@haskell.org> References: <044.6ac0df9e14fafd4394d0f7a94cb2ccc6@haskell.org> Message-ID: <059.41c1f304fde60c920c12b7c19d400ba1@haskell.org> #3376: hpc and CPP don't mix on Windows -------------------------------------+------------------------------------- Reporter: igloo | Owner: andy@? Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Code | Version: 6.10.4 Coverage | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => closed * resolution: => worksforme Comment: This is probably obsolete, seems to work here with GHC 7.8.1 (Haskell Platform 2014.02). {{{ $ ghc -fhpc --make CommonHPC -cpp [1 of 2] Compiling Common ( Common.hs, Common.o ) [flags changed] [2 of 2] Compiling Main ( CommonHPC.hs, CommonHPC.o ) [flags changed] Linking CommonHPC.exe ... $ ./CommonHPC 24 120 24 120 $ cat CommonHPC.exe.tix Tix [ TixModule "Main" 172773183 18 [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], TixModule "Common" 2159774738 8 [2,9,9,9,9,9,9,11]] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 3 22:42:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Nov 2014 22:42:58 -0000 Subject: [GHC] #9712: package "primitive" fails to install under msys2-i686 (Windows) In-Reply-To: <045.44b3a2c6a330919c7f9b94f8f0acc95b@haskell.org> References: <045.44b3a2c6a330919c7f9b94f8f0acc95b@haskell.org> Message-ID: <060.183a7806c7f742333dfa5e56b4df7da2@haskell.org> #9712: package "primitive" fails to install under msys2-i686 (Windows) ---------------------------------------+--------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 7.9 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------- Changes (by gintas): * status: new => closed * resolution: => worksforme Comment: I just tried this with a fresh msys32 installation and did not run into any issues. I also tried installing 'primitive' in a cabal sandbox to be sure, that worked fine too. Closing this for the time being. I'll reopen if I run into this again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 00:27:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 00:27:24 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.7ebe117d1a61e82892b017cdd8c84c2f@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255, | Phab:D399 | -------------------------------------+------------------------------------- Comment (by Polarina): Tabs are generally not the cause for incorrect indentation. It is mixing them with spaces that do. An alternative approach would be to warn if a tab character is preceded by a space. That would keep the tabs people happy, even those that use tabs for indentation and spaces for alignment; while catching most cases of tab/space mix-ups. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 00:31:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 00:31:20 -0000 Subject: [GHC] #7819: FreeBSD without system libffi: Shared object "libffi.so.6" not found In-Reply-To: <044.bc199f920b8945d5966484b8c8921309@haskell.org> References: <044.bc199f920b8945d5966484b8c8921309@haskell.org> Message-ID: <059.c1967ce992858d128a2bc72b6fba6b5a@haskell.org> #7819: FreeBSD without system libffi: Shared object "libffi.so.6" not found -------------------------------------+------------------------------------- Reporter: igloo | Owner: pgj Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Build | Version: 7.6.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): In commit bcc5c953f80c53732172345639f30974b9862043 {{{ Re-enable DYNAMIC_GHC_PROGRAMS for FreeBSD. All actively supported releases (8.4-RELEASE, 9.2-RELEASE and the upcoming 10.0-RELEASE) now support resolution of $ORIGIN properly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 01:33:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 01:33:11 -0000 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> Message-ID: <059.1043e7a5a2e72a65d9df3a9e226eaba7@haskell.org> #1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D433 * milestone: ? => 7.10.1 Comment: Now that splices are run from the renamer, this was relatively easy. However, the resulting code is far from elegant, and I would love some help in making it better. See the Phab:D433 for more info on the inelegant code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 01:48:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 01:48:33 -0000 Subject: [GHC] #8342: System.Directory.getPermissions does not work well on Windows 7 In-Reply-To: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> References: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> Message-ID: <060.430da4e6215521e1979c3c5aabf331ea@haskell.org> #8342: System.Directory.getPermissions does not work well on Windows 7 -------------------------------------+------------------------------------- Reporter: freizl | Owner: leroux Type: bug | Status: upstream Priority: normal | Milestone: Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by freizl): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 01:49:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 01:49:08 -0000 Subject: [GHC] #8342: System.Directory.getPermissions does not work well on Windows 7 In-Reply-To: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> References: <045.c58f233f1e483be83c7bb554709bd796@haskell.org> Message-ID: <060.3e3eabd2e8c927f9a759c0c7368eeb7a@haskell.org> #8342: System.Directory.getPermissions does not work well on Windows 7 -------------------------------------+------------------------------------- Reporter: freizl | Owner: leroux Type: bug | Status: upstream Priority: normal | Milestone: Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by freizl): Open new ticket to "directory" lib. https://github.com/haskell/directory/issues/9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 03:08:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 03:08:11 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.3d37a532478f905360c15db1a29fcac6@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255, | Phab:D399 | -------------------------------------+------------------------------------- Comment (by isaacdupree): re: Polarina: Let's try describing a rule that would catch all suspect uses of tabs. Tabs may not be preceded by a non-tab character: that's a start. Let's add: If two adjacent lines have different numbers of tabs, the line with fewer tabs must have a non-whitespace character following the last tab. This way the layout algorithm will never compare the width of a space and a tab (I think). Except that is not enough when layout is begun on the same line as the layout-inducing keyword: {{{ f x = z where y = x + x z = y + y }}} (Personally I consider it bad style to do that even with spaces. If you change the first line before the layout keyword, you need to change the whole layout. Also if you dare to use a non-monospace font it will look wrong. I prefer starting the layout on a new line. [I wish I had a warning for this.]) I think there is a way to warn exactly when the tab width affects layout, but it would have to happen after lexing, and I'm not volunteering to implement it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 03:14:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 03:14:23 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.ea71db727ae0ed8bb9bd82730428d245@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255, | Phab:D399 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:30 Polarina]: > Tabs are generally not the cause for incorrect indentation. It is mixing them with spaces that do. > > An alternative approach would be to warn if a tab character is preceded by a space. That would keep the tabs people happy, even those that use tabs for indentation and spaces for alignment; while catching most cases of tab/space mix-ups. I don't think that will do the trick, but this ticket's comments aren't the right venue for the discussion. If you have an idea for improving `-fwarn-tabs`, you should open a new ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 08:09:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 08:09:06 -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.3cd4b3204ec17c0df07794705d42f3c8@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): @nh2 I don't think anyone has fully investigated what's going on in #8224. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 08:33:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 08:33:30 -0000 Subject: [GHC] #9764: Home package modules silently override available modules from package database Message-ID: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> #9764: Home package modules silently override available modules from package database -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- To see this, define a module with the same name as some module in base. GHC will compile this: {{{ module Data.List where foo = 2 module A where import Data.List x = print foo }}} This behavior is intentional; the most compelling reason of behaving this way is that if you are calling `ghc` without `-hide-all-packages`, some random package you installed which just happened to provide a module name that conflicted with yours could cause your code to stop compiling if we treated the package database and home packages equally. However, this behavior seems undesirable when `-hide-all-packages` is provided; at the very least, it seems like you might want to provide a warning that you're defining a module which conflicts with a module from a package you have exposed. This behavior will be further undesirable when signatures come into the picture. Now, I will want to include a package containing a signature for `A`, and FURTHERMORE I may want to declare a signature `A.hsig` in the local package which augments this signature with some extra declarations I need. Under the current behavior, the externally imported signature is just ignored entirely, even though I wanted them to be merged together. My proposal is to switch the behavior so that we don't prefer home modules if `-hide-all-packages` is provided. What's not great about this proposal is that it adds yet another discrepancy between bare GHC use and GHC use with `-hide-all-packages`. I'm interested to know what people would like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 08:34:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 08:34:37 -0000 Subject: [GHC] #9764: Home package modules silently override available modules from package database In-Reply-To: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> References: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> Message-ID: <060.db267028ceb82b0d98be203dbc7de60b@haskell.org> #9764: Home package modules silently override available modules from package database -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > To see this, define a module with the same name as some module in base. > GHC will compile this: > > {{{ > module Data.List where > foo = 2 > > module A where > import Data.List > x = print foo > }}} > > This behavior is intentional; the most compelling reason of behaving this > way is that if you are calling `ghc` without `-hide-all-packages`, some > random package you installed which just happened to provide a module name > that conflicted with yours could cause your code to stop compiling if we > treated the package database and home packages equally. > > However, this behavior seems undesirable when `-hide-all-packages` is > provided; at the very least, it seems like you might want to provide a > warning that you're defining a module which conflicts with a module from > a package you have exposed. > > This behavior will be further undesirable when signatures come into the > picture. Now, I will want to include a package containing a signature for > `A`, and FURTHERMORE I may want to declare a signature `A.hsig` in the > local package which augments this signature with some extra declarations > I need. Under the current behavior, the externally imported signature is > just ignored entirely, even though I wanted them to be merged together. > > My proposal is to switch the behavior so that we don't prefer home > modules if `-hide-all-packages` is provided. What's not great about this > proposal is that it adds yet another discrepancy between bare GHC use and > GHC use with `-hide-all-packages`. I'm interested to know what people > would like. New description: To see this, define a module with the same name as some module in base. GHC will compile this: {{{ module Data.List where foo = 2 module A where import Data.List x = print foo }}} This behavior is intentional; the most compelling reason of behaving this way is that if you are calling `ghc` without `-hide-all-packages`, some random package you installed which just happened to provide a module name that conflicted with yours could cause your code to stop compiling if we treated the package database and home packages equally. However, this behavior seems undesirable when `-hide-all-packages` is provided; at the very least, it seems like you might want to provide a warning that you're defining a module which conflicts with a module from a package you have exposed. This behavior will be further undesirable when signatures come into the picture. Now, I will want to include a package containing a signature for `A`, and FURTHERMORE I may want to declare a signature `A.hsig` in the local package which augments this signature with some extra declarations I need. Under the current behavior, the externally imported signature is just ignored entirely, even though I wanted them to be merged together. (A counter argument is that this is confusing for users, who will see the use of a declaration, browse to the local hsig file, and not see it defined; thus this mode of use should be disallowed.) My proposal is to switch the behavior so that we don't prefer home modules if `-hide-all-packages` is provided. What's not great about this proposal is that it adds yet another discrepancy between bare GHC use and GHC use with `-hide-all-packages`. I'm interested to know what people would like. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 08:42:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 08:42:59 -0000 Subject: [GHC] #9765: Strange behavior of GC under ghci Message-ID: <046.c2cf60b9bc80ad55913117a33e63b2e9@haskell.org> #9765: Strange behavior of GC under ghci -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Releasing the result of `newForeignPtr nullFunPtr nullPtr` end in core dump, due to the fact that finalizer function is set to null pointer. When I run something like this in GHCI: {{{#!hs > import System.Mem > import Foreign.Ptr > import Foreign.ForeignPtr > import System.IO.Unsafe > import qualified Data.Map as Map > a <- return $ Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. > print a fromList [(1,0x0000000000000000)] > performGC > ^D Leaving GHCi. [1] 3782 segmentation fault (core dumped) ghci }}} it wont crash until exit from ghci which is correct. But if I do something similar but using `let` binding it will crash even if variable `a` didn't lose its scope {{{#!hs > import System.Mem > import Foreign.Ptr > import Foreign.ForeignPtr > import System.IO.Unsafe > import qualified Data.Map as Map > let a = Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. > print a fromList [(1,0x0000000000000000)] [1] 3842 segmentation fault (core dumped) ghci }}} Why is there a difference between doing it with `do` notation and with `let` binding? I also expected that if I rebind variable `a` it will lose it's scope and will be released but it is not (see below) {{{#!hs > import System.Mem > import Foreign.Ptr > import Foreign.ForeignPtr > import System.IO.Unsafe > import qualified Data.Map as Map > a <- return $ Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. > print a fromList [(1,0x0000000000000000)] > a <- return () -- rebinding varable a, it is no longer used > performGC > -- no crash, varaible a not released }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 08:56:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 08:56:42 -0000 Subject: [GHC] #9748: Disambiguate IO actions in GHCi with :set +t In-Reply-To: <051.eb64c51829f1760c379502433f79e297@haskell.org> References: <051.eb64c51829f1760c379502433f79e297@haskell.org> Message-ID: <066.ba29a5461eb2f7a88903da5f43130113@haskell.org> #9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: | Owner: zudov Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: low | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by zudov): * owner: => zudov -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 09:07:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 09:07:01 -0000 Subject: [GHC] #9742: The default definitions of foldl1 and foldr1 are too strict In-Reply-To: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> References: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> Message-ID: <060.04089ce1e7a5885ba8b27d0497fde3fc@haskell.org> #9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D423 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"6dd218e5f82f19523f9e7aa5371f5bd7beb19663/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6dd218e5f82f19523f9e7aa5371f5bd7beb19663" Make Foldable's foldr1 and foldl1 defaults lazier Fixes #9742. Previously, `foldr1` as applied to a list-like structure would be strict in the spine, and `foldl1` would be strict in the spine of a snoc-list. See also https://www.haskell.org/pipermail/libraries/2014-October/024035.html Differential Revision: https://phabricator.haskell.org/D423 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 09:09:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 09:09:59 -0000 Subject: [GHC] #9081: Template Haskell gets confused with scoped kind variables in a class declaration In-Reply-To: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> References: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> Message-ID: <062.ef324e4b67ea52ab5ec5e0bfef7d3377@haskell.org> #9081: Template Haskell gets confused with scoped kind variables in a class declaration -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T9081 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => th/T9081 Comment: I'll add it as a regression test though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 09:18:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 09:18:39 -0000 Subject: [GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics Message-ID: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> #9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9043 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket serves to track the task of improving the meta-data representation in GHC.Generics as described in the following wiki page: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#Amoreconservativefirstapproachtothisproblem I'm working on this in branch `wip/GenericsMetaData`, and I intend to have it in 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 09:19:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 09:19:53 -0000 Subject: [GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics In-Reply-To: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> References: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> Message-ID: <061.b0a1625e780790ed90d53cc084ea51c6@haskell.org> #9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9043 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * related: 9043 => #9043 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 09:20:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 09:20:07 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.d4e9d707fca5ff5e4e93e81607b2d4f2@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: 9766 Unknown/Multiple | Related Tickets: #8778 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * blockedby: => 9766 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 09:33:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 09:33:14 -0000 Subject: [GHC] #9759: Add Alternative wrapper to Data.Monoid In-Reply-To: <045.9ddae74098f5edc53dc82839cb308d90@haskell.org> References: <045.9ddae74098f5edc53dc82839cb308d90@haskell.org> Message-ID: <060.2e9c7210f95055059e81e7c307ad7ac9@haskell.org> #9759: Add Alternative wrapper to Data.Monoid -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D422 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"49fde3b6764d4b7bb149ef1c2c56d00cf0878ddb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="49fde3b6764d4b7bb149ef1c2c56d00cf0878ddb" Add `Alternative` wrapper to Data.Monoid Complete #9759. Use `coerce` to get nicer definitions of `Sum` and `Product`; update documentation for `First` and `Last`. Reviewed By: hvr Differential Revision: https://phabricator.haskell.org/D422 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 09:46:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 09:46:15 -0000 Subject: [GHC] #9764: Home package modules silently override available modules from package database In-Reply-To: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> References: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> Message-ID: <060.299720d47eeb2a08fc3033147ddcefe9@haskell.org> #9764: Home package modules silently override available modules from package database -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Wait. If you say `-hide-all-packages` then there are no packages in scope, so how can there be any conflict? Perhaps you mean to propose this: * If you have an explicit `-package p` flag * And a home-package module whose name conflicts with one exposed by `p` * Then at least warn of the conflict Was that what you meant? That would not imply any discrepancies, would it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 09:57:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 09:57:10 -0000 Subject: [GHC] #9764: Home package modules silently override available modules from package database In-Reply-To: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> References: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> Message-ID: <060.642df796f107b2c08927b6bf8e599233@haskell.org> #9764: Home package modules silently override available modules from package database -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): That is not what I was proposing, but it sounds much better! And I agree, in that case, there would be no discrepancies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:07:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:07:09 -0000 Subject: [GHC] #9767: Add isSubsequenceOf to Data.List Message-ID: <047.a10d1fc86511a46e367bb032e95edccd@haskell.org> #9767: Add isSubsequenceOf to Data.List -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Niklas Hamb?chen suggested that we add the dual of subsequences, isSubsequenceOf (like isPrefixOf to inits & isSuffixOf to tails)[1]. It was a simple and noncontroversial proposal which received unanimous +1s. [1] https://www.haskell.org/pipermail/libraries/2014-November/024063.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:33:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:33:01 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.c440940e8088fe0f427fb0bc9c6c6e40@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: 7.10.1 request | Version: Priority: normal | Keywords: patterns, pattern Component: Compiler | synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * cc: cactus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:37:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:37:49 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.aa05ce9052baa4f8a7b7514d457ce537@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4723a0e39b5eb7a47457696aceb67f8e230a42e6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4723a0e39b5eb7a47457696aceb67f8e230a42e6" Test Trac #9211 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:37:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:37:49 -0000 Subject: [GHC] #9708: Type inference non-determinism due to improvement In-Reply-To: <046.b82d37e7450cce9a05553877e957cde0@haskell.org> References: <046.b82d37e7450cce9a05553877e957cde0@haskell.org> Message-ID: <061.b96aa82c93dd68840a325c31cf65fb32@haskell.org> #9708: Type inference non-determinism due to improvement -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f861fc6ad8e5504a4fecfc9bb0945fe2d313687c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f861fc6ad8e5504a4fecfc9bb0945fe2d313687c" Test Trac #9708 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:37:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:37:49 -0000 Subject: [GHC] #9747: Odd failure to deduce a constraint In-Reply-To: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> References: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> Message-ID: <061.eae4aecd6d9319f9482b51e37bcf8abc@haskell.org> #9747: Odd failure to deduce a constraint -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: TypeFamilies Operating System: | ConstraintKinds Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: indexed- | Related Tickets: types/should_compile/T9747 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"dbbffb7bd59c2c0d098afacad7c88c53588f0faa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dbbffb7bd59c2c0d098afacad7c88c53588f0faa" Test Trac #9747 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:37:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:37:49 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.5ecd0120e62fa546a55d62bcecb5b059@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | typecheck/should_fail/T9739 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c639560d8ad969415033b19201d9626b1a0638bf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c639560d8ad969415033b19201d9626b1a0638bf" Test Trac #9739 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:37:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:37:49 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.22079712076bb27873f2db77b4352801@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | typecheck/should_fail/T9739 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7c79633688238086ad60e1d23e0a424bb4eb325f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7c79633688238086ad60e1d23e0a424bb4eb325f" Fix the superclass-cycle detection code (Trac #9739) We were falling into an infinite loop when doing the ambiguity check on a class method, even though we had previously detected a superclass cycle. There was code to deal with this, but it wasn't right. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:37:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:37:49 -0000 Subject: [GHC] #9081: Template Haskell gets confused with scoped kind variables in a class declaration In-Reply-To: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> References: <047.fe8a263339c672a80ffdf52fdaf5cb15@haskell.org> Message-ID: <062.4a8550e649192a57bca9834cc7f954e7@haskell.org> #9081: Template Haskell gets confused with scoped kind variables in a class declaration -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T9081 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"09aac7dafc2905603283b6028e4ce7416716bcd6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="09aac7dafc2905603283b6028e4ce7416716bcd6" Test Trac #9081 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:37:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:37:49 -0000 Subject: [GHC] #9750: Core lint failure with TypeLits Symbol In-Reply-To: <046.5556b1a5abfec32c491622ee4b789d38@haskell.org> References: <046.5556b1a5abfec32c491622ee4b789d38@haskell.org> Message-ID: <061.9f77b04129b27740cfc1410794f3f77b@haskell.org> #9750: Core lint failure with TypeLits Symbol -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fe178b2729bb044b401b3fe670d12bcd3d14ad71/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fe178b2729bb044b401b3fe670d12bcd3d14ad71" Test Trac #9750 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:37:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:37:49 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.82c0de727f5ba85edcc98e4751eed8ad@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5770029a1f8509a673b2277287fc8fe90b9b6002/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5770029a1f8509a673b2277287fc8fe90b9b6002" Simon's major commit to re-engineer the constraint solver The driving change is this: * The canonical CFunEqCan constraints now have the form [G] F xis ~ fsk [W] F xis ~ fmv where fsk is a flatten-skolem, and fmv is a flatten-meta-variable Think of them as the name of the type-function application See Note [The flattening story] in TcFlatten. A flatten-meta-variable is distinguishable by its MetaInfo of FlatMetaTv This in turn led to an enormous cascade of other changes, which simplify and modularise the constraint solver. In particular: * Basic data types * I got rid of inert_solved_funeqs altogether. It serves no useful role that inert_flat_cache does not solve. * I added wl_implics to the WorkList, as a convenient place to accumulate newly-emitted implications; see Note [Residual implications] in TcSMonad. * I eliminated tcs_ty_binds altogether. These were the bindings for unification variables that we have now solved by unification. We kept them in a finite map and did the side-effecting unification later. But in cannonicalisation we had to look up in the side-effected mutable tyvars anyway, so nothing was being gained. Our original idea was that the solver would be pure, and would be a no-op if you discarded its results, but this was already not-true for implications since we update their evidence bindings in an imperative way. So rather than the uneasy compromise, it's now clearly imperative! * I split out the flatten/unflatten code into a new module, TcFlatten * I simplified and articulated explicitly the (rather hazy) invariants for the inert substitution inert_eqs. See Note [eqCanRewrite] and See Note [Applying the inert substitution] in TcFlatten * Unflattening is now done (by TcFlatten.unflatten) after solveFlats, before solving nested implications. This turned out to simplify a lot of code. Previously, unflattening was done as part of zonking, at the very very end. * Eager unflattening allowed me to remove the unpleasant ic_fsks field of an Implication (hurrah) * Eager unflattening made the TcSimplify.floatEqualities function much simpler (just float equalities looking like a ~ ty, where a is an untouchable meta-tyvar). * Likewise the idea of "pushing wanteds in as givens" could be completely eliminated. * I radically simplified the code that determines when there are 'given' equalities, and hence whether we can float 'wanted' equalies out. See TcSMonad.getNoGivenEqs, and Note [When does an implication have given equalities?]. This allowed me to get rid of the unpleasant inert_no_eqs flag in InertCans. * As part of this given-equality stuff, I fixed Trac #9211. See Note [Let-bound skolems] in TcSMonad * Orientation of tyvar/tyvar equalities (a ~ b) was partly done during canonicalisation, but then repeated in the spontaneous-solve stage (trySpontaneousSolveTwoWay). Now it is done exclusively during canonicalisation, which keeps all the code in one place. See Note [Canonical orientation for tyvar/tyvar equality constraints] in TcCanonical }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:40:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:40:16 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.cf1567fd16ffec0b384c1cdccef6d922@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | typecheck/should_fail/T9739 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Thanks for reporting this! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:41:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:41:41 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.3a7091934766c018f0d90e21ce66289e@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: indexed- | types/should_compile/T9211 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_compile/T9211 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:44:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:44:19 -0000 Subject: [GHC] #9728: ghci: internal error: ASSERTION FAILED: file rts/Interpreter.c, line 773 In-Reply-To: <045.ebf64d7a8e540c9c1c277bb0fdb153d0@haskell.org> References: <045.ebf64d7a8e540c9c1c277bb0fdb153d0@haskell.org> Message-ID: <060.c266342d5fd6910425d6a9eefab258c8@haskell.org> #9728: ghci: internal error: ASSERTION FAILED: file rts/Interpreter.c, line 773 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.9 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun002 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: same as #9741 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:44:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:44:39 -0000 Subject: [GHC] #9708: Type inference non-determinism due to improvement In-Reply-To: <046.b82d37e7450cce9a05553877e957cde0@haskell.org> References: <046.b82d37e7450cce9a05553877e957cde0@haskell.org> Message-ID: <061.b1b859f51934f1a119b93f2e5e4d103d@haskell.org> #9708: Type inference non-determinism due to improvement -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => diatchki Comment: The test I've added "succeeds" when GHC says there's an error with `ti7`. I'll leave this open, though as a deficiency in the current implementation of type-level naturals. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:45:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:45:47 -0000 Subject: [GHC] #9750: Core lint failure with TypeLits Symbol In-Reply-To: <046.5556b1a5abfec32c491622ee4b789d38@haskell.org> References: <046.5556b1a5abfec32c491622ee4b789d38@haskell.org> Message-ID: <061.aea23b194f78161ca14039dc056edc0d@haskell.org> #9750: Core lint failure with TypeLits Symbol -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9750 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T9750 * resolution: => fixed Comment: Fixed with the new type inference engine; regression test added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:49:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:49:52 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.661a36b5274738be92e92ef1d4fc6d67@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: 7.10.1 request | Version: Priority: normal | Keywords: patterns, pattern Component: Compiler | synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): > The implementation is a straightforward desugaring into pattern synonyms and view patterns That's how I started the work on pattern synonyms in the first place... spoiler alert: it never is :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 10:51:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 10:51:40 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.fd6cd385fc9426b05b8444c34ab406e2@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: 7.10.1 request | Version: Priority: normal | Keywords: patterns, pattern Component: Compiler | synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): +1 to SPJ on distinguishing ''pat'' and ''expr'' arguments. In fact, I think they should be distinguished even when introducing them as formal arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 11:03:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 11:03:52 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.e7b3462b72a0fcb3a757683a3d81d345@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5144 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * cc: cactus (added) * keywords: => pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 11:05:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 11:05:22 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.f829f282e50bebe0f42953b02d9ee048@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Template | Keywords: pattern synonyms Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * cc: cactus (added) * keywords: => pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 11:12:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 11:12:05 -0000 Subject: [GHC] #9748: Disambiguate IO actions in GHCi with :set +t In-Reply-To: <051.eb64c51829f1760c379502433f79e297@haskell.org> References: <051.eb64c51829f1760c379502433f79e297@haskell.org> Message-ID: <066.3c5a9537df5fe6c822e32405d097009d@haskell.org> #9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: | Owner: zudov Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: low | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:3 simonpj]: > I quite like Herert's suggestion. Or > {{{ > Prelude> return 'a' > Running IO action... > 'a' > it :: Char > }}} This has the risk of interleaving with other side-effected output the `IO` action may produce > or > {{{ > Prelude> return 'a' > it :: Char -- After running the IO action > }}} This has the issue of introducing an English sentence which may require translation to other language (should GHCi ever be i18n'ed), as well as using up precious horizontal space for a boilerplate expression. I'd rather avoid adding natural language in places where a more terse annotation would suffice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 14:23:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 14:23:08 -0000 Subject: [GHC] #9768: reify returns only first instance of class Message-ID: <045.83e92240abc133afcb63c56242e950b3@haskell.org> #9768: reify returns only first instance of class -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | https://gist.github.com/qnikst/b93e7154e78bcc159be2 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In ghc-7.8 reify returns only first data type that have an instance, here is a code: Test.hs {{{ {-# LANGUAGE TemplateHaskell #-} module Test where import Language.Haskell.TH class C a inner :: ExpQ inner = do ClassI _ instances <- reify ''C let sh = show instances [| sh |] def :: String -> DecsQ def x = let dn = mkName x in do dt <- dataD (cxt []) dn [] [] [] i <- instanceD (cxt []) (appT (conT ''C) (conT dn)) [] -- [d| instance C $(cn) |] return [dt,i] test :: ExpQ test = [| print $inner |] }}} test.hs {{{ {-# LANGUAGE TemplateHaskell #-} import Test def "A" def "B" main = $(test) }}} running test returns: "[InstanceD [] (AppT (ConT Test.C) (ConT Main.A)) []]" under 7.6 test returns: "[InstanceD [] (AppT (ConT Test.C) (ContT Main.B) [], InstanceD [] (AppT (ConT Test.C) (ConT Main.A) []]" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 15:53:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 15:53:58 -0000 Subject: [GHC] #9768: reify returns only first instance of class In-Reply-To: <045.83e92240abc133afcb63c56242e950b3@haskell.org> References: <045.83e92240abc133afcb63c56242e950b3@haskell.org> Message-ID: <060.e1f739fc6ed4e33204a8aa0837dd238b@haskell.org> #9768: reify returns only first instance of class -------------------------------------+------------------------------------- Reporter: qnikst | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | https://gist.github.com/qnikst/b93e7154e78bcc159be2| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: If you change your `test.hs` to {{{ {-# LANGUAGE TemplateHaskell #-} import Test def "A" def "B" $(return []) main = $(test) }}} it works. The extra splice changes the order of processing of top-level blocks. GHC breaks a module into a sequence of mutually-recursive blocks, separated by top-level declaration splices. But, it seems that the processing of these blocks does not proceed in strict top-to-bottom order. This doesn't quite go against spec -- TH claims to process splices in a non-deterministic order -- but I think we can do better for top-level declaration splices. I'll take a look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 15:54:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 15:54:55 -0000 Subject: [GHC] #9768: Declarations processed in unexpected order in the presence of TH declaration splices (was: reify returns only first instance of class) In-Reply-To: <045.83e92240abc133afcb63c56242e950b3@haskell.org> References: <045.83e92240abc133afcb63c56242e950b3@haskell.org> Message-ID: <060.a5b84d557d076d43f90e52132cecd229@haskell.org> #9768: Declarations processed in unexpected order in the presence of TH declaration splices -------------------------------------+------------------------------------- Reporter: qnikst | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | https://gist.github.com/qnikst/b93e7154e78bcc159be2| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 16:31:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 16:31:20 -0000 Subject: [GHC] #9765: Strange behavior of GC under ghci In-Reply-To: <046.c2cf60b9bc80ad55913117a33e63b2e9@haskell.org> References: <046.c2cf60b9bc80ad55913117a33e63b2e9@haskell.org> Message-ID: <061.3b71089205db50c69063f590feedbaf3@haskell.org> #9765: Strange behavior of GC under ghci -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): > Why is there a difference between doing it with `do` notation and with `let` binding? Well, this part is easy: the `let` binding is generalized over the type of the numeric literal `1`, so that `a` is really a function that constructs a new Map and a new ForeignPtr each time it is called (evaluated). The result in the `do` notation is not generalized, and is really a Map. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 17:52:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 17:52:49 -0000 Subject: [GHC] #9768: Declarations processed in unexpected order in the presence of TH declaration splices In-Reply-To: <045.83e92240abc133afcb63c56242e950b3@haskell.org> References: <045.83e92240abc133afcb63c56242e950b3@haskell.org> Message-ID: <060.fb7f938d0f9bd2f90a795fca6c94885d@haskell.org> #9768: Declarations processed in unexpected order in the presence of TH declaration splices -------------------------------------+------------------------------------- Reporter: qnikst | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | https://gist.github.com/qnikst/b93e7154e78bcc159be2| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * cc: facundo.dominguez (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 19:01:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 19:01:50 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.a93f4ef945b3a325c3acfee15601ccf9@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: 9526 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): An IRC discussion suggests not adding `Binary` instances: hvr 1:32 goldfire: well, we only recently dropped the containers dep in template-haskell to not force users wanting to use TH to a specific containers verison hvr 1:32 goldfire: adding dep on 'binary' would be rather undesirable in that respect goldfire 1:32 hvr: That makes sense. 1:33 hvr: Does this get mitigated at all by the Backpack work? hvr 1:33 goldfire: no idea tbh goldfire 1:33 Because my (very loose) understanding is that multiple versions of the same package can now coexist peacefully. 1:34 So, a TH client that doesn't use the Binary instances would be welcome to use a different version of the binary package. 1:34 But, a TH client that wanted to use the TH Binary instances would be tied to the specific version of binary that TH ships with, lest they get type errors. 1:35 ezyang: Care to comment on my and hvr's discussion just now? ezyang 1:46 goldfire, hvr: As with everything, this comes with the caveat that Cabal doesn't know how to handle this, but yes, in principle this is possible with the new change rwbarton 1:47 sounds like it would make sense to wait until 7.12 to add those instances goldfire 1:47 rwbarton: Yes, that's the conclusion I'm coming to. luite: Care to counter? rwbarton 1:48 since the out-of-process TH most likely won't land in 7.10 anyways right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 19:05:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 19:05:12 -0000 Subject: [GHC] #9769: ghc-7.8.3-x86_64-unknown-mingw32.tar.xz missing User's Guide Message-ID: <051.92b9ec823fa5402a4972db991a6f829e@haskell.org> #9769: ghc-7.8.3-x86_64-unknown-mingw32.tar.xz missing User's Guide -------------------------------------+------------------------------------- Reporter: Dangthrimble | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Difficulty: Unknown | Documentation bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Context: I am relatively new to Haskell and am trying to build a Haskell IDE around `Sublime Text`. I have been using `Haskell Platform` but have encountered a number of problems using `cabal`. Consequently I have been advised to uninstall `Haskell Platform` and download `ghc`. I have just downloaded and extracted `ghc-7.8.3-x86_64-unknown- mingw32.tar.xz`. Hoping for advice on setting up `ghc`, I have opened `ghc-7.8.3\doc\html\index.html` in Firefox and clicked on "The User's Guide". Unfortunately the `ghc-7.8.3/doc/html/users_guide` folder is missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 19:52:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 19:52:06 -0000 Subject: [GHC] #9764: Home package modules silently override available modules from package database In-Reply-To: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> References: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> Message-ID: <060.999e2a7402dd9fd790ad3f005ecd5df2@haskell.org> #9764: Home package modules silently override available modules from package database -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Yuras): If I understand it correctly, it will break my `-Wall`'d code. I sometimes have local Prelude module to work around some incompatibilities between versions: {{{ #!haskell {-# LANGUAGE PackageImports #-} {-# LANGUAGE CPP #-} module Prelude ( module P ) where #if MIN_VERSION_base(4,6,0) import "base" Prelude as P #else import "base" Prelude as P hiding (catch) #endif }}} There are other ways to do that, so I'm not advocating against the proposal. But that is a legitimate use case IMO, and it can be used not only for Prelude. So at least a switch to turn off the warning should be provided, please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 20:23:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 20:23:43 -0000 Subject: [GHC] #9764: Home package modules silently override available modules from package database In-Reply-To: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> References: <045.c611384dbc686471200b2ebf01fe484a@haskell.org> Message-ID: <060.36425830c695bdbe66cb834e37d46ddd@haskell.org> #9764: Home package modules silently override available modules from package database -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): In GHC 7.10, there will be TWO ways to do the specific use-case you're asking for! The first is the new `-prelude-is` flag #9499, which will let you set Prelude to be a module not named Prelude. The second is package renaming #9375, which means you can include base but rename Prelude to another name BasePrelude. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 21:41:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 21:41:45 -0000 Subject: [GHC] #9770: GHC Parser fails on Haddock comment on parameter of a function record field Message-ID: <044.6605f3c60f34bfc83935db1034506191@haskell.org> #9770: GHC Parser fails on Haddock comment on parameter of a function record field -------------------------------------+------------------------------------- Reporter: boris | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: Haddock | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I tried to document parameter of a function that is a record field. The Haddock fails with parse error on input ?->? {{{ data D = D { field :: () -- ^ parameter -> () } }}} Please see https://github.com/haskell/haddock/issues/343 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 21:52:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 21:52:16 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.9aa24ca8bc44570a4c8591df87fbcd45@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: 9526 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab: D437 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab: D437 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 21:52:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 21:52:31 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.87bfe07fa044070fb0bff0b8b35cba01@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: 9526 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D437 | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: Phab: D437 => Phab:D437 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 21:55:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 21:55:10 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.f5896a4bc090d2d32e3613f7300a6c17@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D439 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D439 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 21:56:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 21:56:48 -0000 Subject: [GHC] #9064: Support default class method signatures in Template Haskell In-Reply-To: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> References: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> Message-ID: <062.d146d58460303875e5cf439e226ba870@haskell.org> #9064: Support default class method signatures in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D440 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D440 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 22:05:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 22:05:04 -0000 Subject: [GHC] #9703: Add missing calling conventions to Template Haskell In-Reply-To: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> References: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> Message-ID: <059.c5254639da4e46563cc69b1141191e5e@haskell.org> #9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: cmsaperstein Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D353 | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: ekmett => cmsaperstein * differential: D353 => Phab:D353 Comment: Let me know if you want any further assistance with this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 22:30:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 22:30:22 -0000 Subject: [GHC] #9768: Declarations processed in unexpected order in the presence of TH declaration splices In-Reply-To: <045.83e92240abc133afcb63c56242e950b3@haskell.org> References: <045.83e92240abc133afcb63c56242e950b3@haskell.org> Message-ID: <060.b2fcb29132f44ce9a6ef641610f8537d@haskell.org> #9768: Declarations processed in unexpected order in the presence of TH declaration splices -------------------------------------+------------------------------------- Reporter: qnikst | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | https://gist.github.com/qnikst/b93e7154e78bcc159be2| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: GHC's current behavior is actually exactly as advertised (although perhaps unintuitive). From section 7.16.1 of the manual: A declaration group is the group of declarations created by a top- level declaration splice, plus those following it, down to but not including the next top-level declaration splice. The first declaration group in a module includes all top-level definitions down to but not including the first top-level declaration splice. Thus, in the OP's code, `def "B"` and `main` are in the same group, and accordingly, a splice within that group can't reify the group's own types. This could be changed easily enough, but I think a change would make TH strictly less expressive. Using the current behavior, a splice could include part of a declaration (say, just a type signature) and the rest of the declaration can be hand-written outside the splice. If we made a top- level splice its own inviolable group, such a split declaration would be impossible to write. So, I'm closing this ticket, as everything seems OK to me. Do reopen if this is really ruining your day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 4 22:45:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Nov 2014 22:45:04 -0000 Subject: [GHC] #9768: Declarations processed in unexpected order in the presence of TH declaration splices In-Reply-To: <045.83e92240abc133afcb63c56242e950b3@haskell.org> References: <045.83e92240abc133afcb63c56242e950b3@haskell.org> Message-ID: <060.c4f04dc3dc469cfc5748b356736a1adb@haskell.org> #9768: Declarations processed in unexpected order in the presence of TH declaration splices -------------------------------------+------------------------------------- Reporter: qnikst | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | https://gist.github.com/qnikst/b93e7154e78bcc159be2| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by qnikst): Fair enough. Anyway workaround with adding a `$(return [])` will work for me. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 05:28:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 05:28:15 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.253b71c57b48dcba898239c908fd0bc5@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.10.4 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #2258 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by VictorDenisov): * owner: => VictorDenisov -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 07:34:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 07:34:33 -0000 Subject: [GHC] #9771: Excessive memory usage compiling T3064 Message-ID: <042.84d31aae5dbeacb6c2c61f31caf478e6@haskell.org> #9771: Excessive memory usage compiling T3064 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- With 64dc4d1085a7db375f6532362bf7e23fac3a25eb the testsuite suffers from T3064 allocating an excessive amount of memory (several GiBs) and finally getting killed due to timeout and/or out-of-memory. {{{ =====> T3064(normal) 3054 of 4150 [0, 0, 0] cd ./perf/compiler && '/home/hvr/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno- ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 Compile failed (status 35072) errors were: Killed Failed to find field: peak_megabytes_allocated *** framework failure for T3064(normal) do_test exception Traceback (most recent call last): File "/home/hvr/ghc/testsuite/driver/testlib.py", line 793, in do_test result = func(*[name,way] + args) File "/home/hvr/ghc/testsuite/driver/testlib.py", line 995, in compile return do_compile( name, way, 0, '', [], extra_hc_opts ) File "/home/hvr/ghc/testsuite/driver/testlib.py", line 1024, in do_compile result = simple_build( name, way, extra_hc_opts, should_fail, top_mod, 0, 1, force, override_flags ) File "/home/hvr/ghc/testsuite/driver/testlib.py", line 1262, in simple_build statsResult = checkStats(name, way, stats_file, opts.compiler_stats_range_fields) File "/home/hvr/ghc/testsuite/driver/testlib.py", line 1136, in checkStats val = int(m.group(1)) AttributeError: 'NoneType' object has no attribute 'group' OVERALL SUMMARY for test run started at Wed Nov 5 08:29:10 2014 CET 0:04:14 spent to go through 4150 total tests, which gave rise to 16187 test cases, of which 16186 were skipped 0 had missing libraries 0 expected passes 0 expected failures 1 caused framework failures 0 unexpected passes 0 unexpected failures 0 unexpected stat failures make[1]: Leaving directory '/home/hvr/ghc/testsuite/tests' real 4m13.317s user 3m49.476s sys 0m5.831s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 07:34:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 07:34:46 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.0381f9a83021d2d188255809da916371@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by lukexi): * cc: lukexi@? (added) * priority: normal => high * status: closed => new * resolution: fixed => * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 07:38:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 07:38:50 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.170c066a40038d3292dfe26fc8d9e4d0@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by lukexi): * status: new => patch Comment: Hello! This patch finishes ARM64 support including SMP and means we can now run on the newest 64-bit iOS devices. Would be awesome to get this into 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 07:41:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 07:41:25 -0000 Subject: [GHC] #9771: Excessive memory usage compiling T3064 In-Reply-To: <042.84d31aae5dbeacb6c2c61f31caf478e6@haskell.org> References: <042.84d31aae5dbeacb6c2c61f31caf478e6@haskell.org> Message-ID: <057.91fd5da54f7604d83d7a45ab8f17a7b8@haskell.org> #9771: Excessive memory usage compiling T3064 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"77f8221103a98b38384edd8c2caae6cc2c4ffd72/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="77f8221103a98b38384edd8c2caae6cc2c4ffd72" Temporarily disable T3064 (see #9771) This disables T3064 temporarily as it puts a strain on buildbots during validation exhausting all available memory. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 08:09:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 08:09:50 -0000 Subject: [GHC] #9761: Foldable cannot be derived by GND due to redundant contexts In-Reply-To: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> References: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> Message-ID: <060.822b67b5b867461c99bb8f3fc9496dfc@haskell.org> #9761: Foldable cannot be derived by GND due to redundant contexts -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D425 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"0a8e8995fd31dd46fa9bdbc7f65984b51c8c13dc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0a8e8995fd31dd46fa9bdbc7f65984b51c8c13dc" Remove redundant contexts from Foldable methods New `Foldable` methods accidentally had `Foldable` contexts, which led to type roles being assigned incorrectly and preventing GND from deriving `Foldable` instances. Removing those fixes #9761. Moreover, this patch takes advantage of this fix by deriving `Foldable` (and `Eq`) for `UniqFM`. Differential Revision: https://phabricator.haskell.org/D425 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 08:09:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 08:09:53 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.43d92c53fc3882b0adee9359beaab37b@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 08:53:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 08:53:37 -0000 Subject: [GHC] #9772: Building documentation alone is broken Message-ID: <048.184975ea5e9493595c61ee0ae101aa72@haskell.org> #9772: Building documentation alone is broken -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment it seems that the only way to build documentation is to actually build all of GHC, which is nonsense. Methods of building documentation described in Building/Docs are broken: {{{ To build just the Haddock docs for a given library, do this: cd libraries/base make html stage=0 FAST=YES }}} That ends with errors. See `haddock_for_lib.log` attachement. {{{ To build a document on its own, for example the Users Guide, do this: cd docs/users_guide make html stage=0 FAST=YES substitute 'html' for 'pdf' or 'ps' to build other types of documentation. }}} That also ends with errors. See `users_guide.log` attachement. For above experiments I used the following lines in my `mk/build.mk` file: {{{ HADDOCK_DOCS = YES BUILD_DOCBOOK_HTML = YES BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO }}} Then I run `perl boot && ./configure`. I didn't run `make`, just the above instructions. My configure returns this: {{{ Configure completed successfully. Building GHC version : 7.9.20141105 Build platform : x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : x86_64-unknown-linux Bootstrapping using : /home/killy/.ghc-sandbox/bin/ghc which is version : 7.8.3 Using gcc : /usr/bin/gcc which is version : 4.5.1 Building a cross compiler : NO cpp : /usr/bin/gcc cpp-flags : -E -undef -traditional ld : /usr/bin/ld Happy : /home/killy/.cabal/bin/happy (1.19.4) Alex : /home/killy/.cabal/bin/alex (3.1.3) Perl : /usr/bin/perl dblatex : /usr/bin/dblatex xsltproc : /usr/bin/xsltproc Using LLVM tools llc : /usr/bin/llc opt : /usr/bin/opt HsColour : /home/killy/.cabal/bin/HsColour Building DocBook HTML documentation : NO Building DocBook PS documentation : YES Building DocBook PDF documentation : YES }}} I'm setting the milestone to 7.10.1. It's annoying to have this feature of the build system broken and it would be great to have this fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 08:58:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 08:58:29 -0000 Subject: [GHC] #9771: Excessive memory usage compiling T3064 In-Reply-To: <042.84d31aae5dbeacb6c2c61f31caf478e6@haskell.org> References: <042.84d31aae5dbeacb6c2c61f31caf478e6@haskell.org> Message-ID: <057.0ae3d20a8c1f238369932ced32957068@haskell.org> #9771: Excessive memory usage compiling T3064 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks Herbert. I'll look into this. There really ought to be a way to ensure that tests don't go AWOL and eat all resources, though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 09:36:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 09:36:38 -0000 Subject: [GHC] #9765: Strange behavior of GC under ghci In-Reply-To: <046.c2cf60b9bc80ad55913117a33e63b2e9@haskell.org> References: <046.c2cf60b9bc80ad55913117a33e63b2e9@haskell.org> Message-ID: <061.3c333b741e00e7aed133d779d5ed981e@haskell.org> #9765: Strange behavior of GC under ghci -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): I did some analysis in http://stackoverflow.com/a/26734895/946226 and it is the `ClosureEnv` in the `Linker` module that keeps hold of the bound `HValues`, even when the binding is shadowed. The `ClosureEnv` is a `NameEnv`, so its keys are `Uniques`, and obviously new bindings get new uniques, so the interpreter code should, upon adding a new binding to it, check if some other names are out of scope now and remove them from the `ClosureEnv`. This would allow them to be GC?ed (if nothing else references them, of course). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 09:39:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 09:39:54 -0000 Subject: [GHC] #9773: Binding ImplicitParams in lambda results in parse error Message-ID: <050.de4a6169c289e0e1fb9c171d3210bcac@haskell.org> #9773: Binding ImplicitParams in lambda results in parse error -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ImplicitParams}}} currently do not play well with lambdas :( == Steps to reproduce Create a file {{{Foo.hs}}} with the following content: {{{ {-# LANGUAGE ImplicitParams #-} import Control.Monad foo :: (?bar :: Int) => IO () foo = print ?bar main = do forM_ [1..3] $ \ ?bar -> foo }}} === Expected result {{{ $ runhaskell Foo.hs 1 2 3 }}} === Actual result {{{ $ runhaskell Foo.hs Foo.hs:9:21: Parse error in pattern: ?bar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 09:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 09:45:32 -0000 Subject: [GHC] #9773: Binding ImplicitParams in lambda results in parse error In-Reply-To: <050.de4a6169c289e0e1fb9c171d3210bcac@haskell.org> References: <050.de4a6169c289e0e1fb9c171d3210bcac@haskell.org> Message-ID: <065.a102f657d1e8a8bde609cf6b723baf67@haskell.org> #9773: Binding ImplicitParams in lambda results in parse error -------------------------------------+------------------------------------- Reporter: | Owner: SimonHengel | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: invalid | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Well that really is syntactically illegal, isn't it? You can't explicitly lambda-abstract over an implicit parameter. Reopen if you disagree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 09:56:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 09:56:38 -0000 Subject: [GHC] #9771: Excessive memory usage compiling T3064 In-Reply-To: <042.84d31aae5dbeacb6c2c61f31caf478e6@haskell.org> References: <042.84d31aae5dbeacb6c2c61f31caf478e6@haskell.org> Message-ID: <057.a81c0cf8ee196849a9ceee533b8681e3@haskell.org> #9771: Excessive memory usage compiling T3064 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:2 simonpj]: > There really ought to be a way to ensure that tests don't go AWOL and eat all resources, though. Well, one could either pass some +RTS options to ghc to limit its heap via `-M` (which otoh distorts GHC's reported memory stats, and relies on the RTS to correctly enforce that limit), or (at least on Linux, so I'm not sure what to do for Windows buildbots) you can use `ulimit` to impose a memory allocation limit for a process (and its children). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 10:50:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 10:50:53 -0000 Subject: [GHC] #9773: Binding ImplicitParams in lambda results in parse error In-Reply-To: <050.de4a6169c289e0e1fb9c171d3210bcac@haskell.org> References: <050.de4a6169c289e0e1fb9c171d3210bcac@haskell.org> Message-ID: <065.f295262068fb8a4e0cc5a46b760c07b1@haskell.org> #9773: Binding ImplicitParams in lambda results in parse error -------------------------------------+------------------------------------- Reporter: | Owner: SimonHengel | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: invalid | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by SimonHengel): As I understand it I have to explicitly bind an implicit parameter somewhere to bring it "into scope". At least intuitively I would assume that if {{{ forM_ [1..3] $ \ bar -> let ?bar = bar in foo }}} works, then {{{ forM_ [1..3] $ \ ?bar -> let ?bar = bar in foo }}} should work too. But I realize that the current behavior is clearly laid out in the User's Guide. So it's certainly not a bug, but (if anything) a feature request. Are there any fundamental limitations that would prevent us to make this work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 11:28:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 11:28:59 -0000 Subject: [GHC] #9773: Binding ImplicitParams in lambda results in parse error In-Reply-To: <050.de4a6169c289e0e1fb9c171d3210bcac@haskell.org> References: <050.de4a6169c289e0e1fb9c171d3210bcac@haskell.org> Message-ID: <065.beb3e32e4a8f4ce45e27785ee4dd8717@haskell.org> #9773: Binding ImplicitParams in lambda results in parse error -------------------------------------+------------------------------------- Reporter: | Owner: SimonHengel | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: invalid | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): If you mean that the latter could be syntactic sugar for the former, then I yes I suppose you could do that, but I think it'd be pretty confusing. Worth reading the original paper too: http://galois.com/wp- content/uploads/2014/08/pub_JL_ImplicitParameters.pdf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 11:42:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 11:42:54 -0000 Subject: [GHC] #9767: Add isSubsequenceOf to Data.List In-Reply-To: <047.a10d1fc86511a46e367bb032e95edccd@haskell.org> References: <047.a10d1fc86511a46e367bb032e95edccd@haskell.org> Message-ID: <062.503eaadd92a4ea89ca7d7175ffbe4e57@haskell.org> #9767: Add isSubsequenceOf to Data.List -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"40b1ee4043fefdd19ff6614a63939002840c6d97/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="40b1ee4043fefdd19ff6614a63939002840c6d97" Add `isSubsequenceOf` to Data.List (#9767) Niklas Hamb?chen suggested that we add the dual of `subsequences`, isSubsequenceOf (like `isPrefixOf` to `inits` & `isSuffixOf` to `tails`). It was a simple and noncontroversial proposal which passed unanimously. For more details see the original proposal discussion at https://www.haskell.org/pipermail/libraries/2014-November/024063.html Differential Revision: https://phabricator.haskell.org/D435 Signed-off-by: Alexander Berntsen }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 12:30:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 12:30:17 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.08927523392fb6ce9840386a4a926356@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Comment (by hvr): @ross, I noticed you already reversed the Identity<->Class import-dependency in recent `transformers` commmits I've adapted http://git.haskell.org/packages/transformers.git/commitdiff/refs/heads/wip/T9664 which is now a rather minimal change to `transformers` (i.e. moving the `Identity.hs` file into a different source folder, and adapting `.cabal`) You write you "like to avoid a release with conditional exports". What problems do you anticipate that could occur by making use of such a conditional (non)export of `Data.Functor.Identity`? Specifically, I used `impl(ghc>=7.9)` instead of Cabal flags in order to avoid any Cabal-related problems I could think of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 13:29:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 13:29:26 -0000 Subject: [GHC] #7192: Bug in -fregs-graph with -fnew-codegen In-Reply-To: <047.02bc9a5f0f505473646ec990f1bc4bac@haskell.org> References: <047.02bc9a5f0f505473646ec990f1bc4bac@haskell.org> Message-ID: <062.be40010ca747b2f40151131a7b4e309b@haskell.org> #7192: Bug in -fregs-graph with -fnew-codegen -------------------------------------+------------------------------------- Reporter: simonmar | Owner: benl Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4258 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): This is marked as fixed, but the `-fregs-graph` flag is still disabled for `-O` and `-O2`. Can I re-enabled it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 13:36:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 13:36:01 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.9a791c7b33dc4a51bae001b9184c20d2@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by jstolarek: Old description: > At the moment the Static Argument Transformation (SAT) optimisation is > not run unless explicitly enabled with `-fstatic-argument- > transformation`. The comment in DynFlags says: > > {{{ > Max writes: I think it's probably best not to enable SAT with -O2 for the > 6.10 release. The version of SAT in HEAD at the moment doesn't > incorporate > several improvements to the heuristics, and I'm concerned that without > those changes SAT will interfere with some attempts to write "high > performance Haskell", as we saw in some posts on Haskell-Cafe earlier > this year. In particular, the version in HEAD lacks the tail call > criterion, so many things that look like reasonable loops will be > turned into functions with extra (unneccesary) thunk creation. > }}} > > 6.10 was a long time ago. Has anything changed since then? Does it make > sense to enable that optimisation now? What are the mentioned heuristics > and were they finally implemented? Does anyone know what Haskell-cafe > posts does Max refer to? New description: At the moment the Static Argument Transformation (SAT) optimisation is not run unless explicitly enabled with `-fstatic-argument-transformation`. There was a comment by Max Bolingbroke in DynFlags that said this (that comment is now removed and replaced with a reference to this ticket): {{{ Max writes: I think it's probably best not to enable SAT with -O2 for the 6.10 release. The version of SAT in HEAD at the moment doesn't incorporate several improvements to the heuristics, and I'm concerned that without those changes SAT will interfere with some attempts to write "high performance Haskell", as we saw in some posts on Haskell-Cafe earlier this year. In particular, the version in HEAD lacks the tail call criterion, so many things that look like reasonable loops will be turned into functions with extra (unneccesary) thunk creation. }}} 6.10 was a long time ago. Has anything changed since then? Does it make sense to enable that optimisation now? What are the mentioned heuristics and were they finally implemented? Does anyone know what Haskell-cafe posts does Max refer to? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 14:02:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 14:02:31 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.67c0dcd805cb5f9df9189611ce04f1b4@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Note to self: document `-fllvm-pass-vectors-in-regs` and `fllvm-tbaa` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 14:21:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 14:21:36 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.af76aee01bd5a53ad3f215ce0ca7a73d@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Note to self: `-msse4.2` mentioned in the section 4.16 seems to have been removed. There are also some new flags added by Geoffrey: `-mavx2`, `-mavx512cd`, `-mavx512er`, `-mavx512f` and `-mavx512pf`. I'm unable to document these, need to ask Geoffrey. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 14:28:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 14:28:52 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.27f95633b6531af48882f201eef90bcc@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): @jan, the -mavx2 and -mavx512* flags are currently unused in practice. They SHOULD NOT be documented in a user facing way till they actually do anything meaningful. Which they currently dont in practice. wrt -msse4.2, austin has generalized things so that GHC now has proper -march etc style flags afaict, the msse4.2 stuff should be there afaik -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 14:46:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 14:46:44 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.8925e7ac615f98e0a05614bd4f0baa8c@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Carter: thanks. Indeed, `-msse4.2` is still there, it's just that auto- completion doesn't show it for some reason. Note to self: ask Nicolas Frisby about `-fdmd-tx-dict-sel` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 14:59:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 14:59:23 -0000 Subject: [GHC] #9647: allocation of 10790760 bytes too large In-Reply-To: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> References: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> Message-ID: <059.5e9d47fead034da949c96925ff7fb89f@haskell.org> #9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: run time Operating System: | insufficient memory Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: #8568 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #8568 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 14:59:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 14:59:51 -0000 Subject: [GHC] #8568: internal error: allocation of ... bytes too large In-Reply-To: <047.44f15a8730cfbfb111ae73ca03abf808@haskell.org> References: <047.44f15a8730cfbfb111ae73ca03abf808@haskell.org> Message-ID: <062.0ccae23205ed6380668f18609e4ff1c1@haskell.org> #8568: internal error: allocation of ... bytes too large -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9647 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #9647 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 18:11:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 18:11:07 -0000 Subject: [GHC] #9774: Type error messages containing calls to assert could be prettier. Message-ID: <044.c71fc52331933a746aaeda39862422da@haskell.org> #9774: Type error messages containing calls to assert could be prettier. -------------------------------------+------------------------------------- Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following piece of code contains a type error. It also contains a call to `assert`. {{{#!hs import Control.Exception.Assert main = putStrLn (assert True 'a') }}} GHC 7.8.3 reports the type error as follows: {{{ Err.hs:3:30: Couldn't match type ?Char? with ?[Char]? Expected type: String Actual type: Char In the third argument of ?GHC.IO.Exception.assertError?, namely ?'a'? In the first argument of ?putStrLn?, namely ?(GHC.IO.Exception.assertError "Err.hs:3:18-23"## True 'a')? In the expression: putStrLn (GHC.IO.Exception.assertError "Err.hs:3:18-23"## True 'a') }}} The calls to `assert` has already been desugared, which is not necessarily very readable. I think it would be better if GHC just printed the call to `assert` as it appeared in the source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 18:21:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 18:21:28 -0000 Subject: [GHC] #9741: Interpreter stack checks are not quite right In-Reply-To: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> References: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> Message-ID: <061.54ebcf3cc9da196b9c73b893e499e7eb@haskell.org> #9741: Interpreter stack checks are not quite right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: It turns out that things were working mostly correctly, and there was no danger of a segfault. SpLim has a certain amount of headroom to allow for the space needed to save things when a stack check fails, which is why we appeared to be going over the limit sometimes. The assertion was the bug. However, I did find some other bugs while tracking this down, the patches I committed are: 83cf31e42e87e93eda3e576bc5935509959c2f49 4cd277b4dcb91c6c6aa7e071ef0364570566de37 4cd277b4dcb91c6c6aa7e071ef0364570566de37 e6b38294512896cf55f2d05d09d742d82313f598 081ef2fb351831081bf6851fd3907679b1b98405 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 19:03:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 19:03:05 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.07df8aba7ed222e72a92acb99dda980a@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to `ghc-7.8` (after a bit of pain). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 20:00:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 20:00:30 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.4364ec98873cdb42b42e39339a3daeb7@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: Phab:D444 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D444 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 20:22:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 20:22:47 -0000 Subject: [GHC] #9741: Interpreter stack checks are not quite right In-Reply-To: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> References: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> Message-ID: <061.ea99a7668de4493f2e2cc2d5a2c3b583@haskell.org> #9741: Interpreter stack checks are not quite right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Well done -- thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 5 22:45:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Nov 2014 22:45:29 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs Message-ID: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The Windows build over here spews a bunch of errors during the build like the ones below. All of them seem to be related to hsc2hs. The errors do not the build for some reason, so the problem is not critical, but we should look into what's going on here. Note that the errors are indeterministic and the set of files affected varies between builds. Examples: {{{ ghctrace.2/3.log:Failed to remove file libraries/base/dist- install/build/System/CPUTime_hsc_make.exe; error= DeleteFile "libraries/base/dist-install/build/System/CPUTime_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file compiler/stage2/build/Fingerprint_hsc_make.exe; error= DeleteFile "compiler/stage2/build/Fingerprint_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/1.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/4.log:Failed to remove file libraries/old-time/dist- install/build/System/Time_hsc_make.exe; error= DeleteFile "libraries/old- time/dist-install/build/System/Time_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/5.log:Failed to remove file libraries/Win32/dist- install/build/Graphics/Win32/GDI/Pen_hsc_make.exe; error= DeleteFile "libraries/Win32/dist-install/build/Graphics/Win32/GDI/Pen_hsc_make.exe": permission denied (Access is denied.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 01:57:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 01:57:14 -0000 Subject: [GHC] #9652: Bootstrapping GHC HEAD against itself doesn't work In-Reply-To: <045.174cce8060d844f9c120636e662de792@haskell.org> References: <045.174cce8060d844f9c120636e662de792@haskell.org> Message-ID: <060.a64281241fc978cc5be9b85eeeddffc9@haskell.org> #9652: Bootstrapping GHC HEAD against itself doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => highest * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 07:36:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 07:36:51 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.ec5e78368bb565d6908d30e2ac5086d5@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): Status report Phab:D297 has been withdrawn, as it has been split up into * the changes required to the AST in Phab:D426 * the changes for the Lexer/Parser etc in Phab:D438 * changes to HsLit to capture the original source text in Phab:D412 At this point Phab:D412 is set up to depend on Phab:D438 which in turn depends on Phab:D426 These are all ready for review -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 07:38:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 07:38:42 -0000 Subject: [GHC] #9765: Strange behavior of GC under ghci In-Reply-To: <046.c2cf60b9bc80ad55913117a33e63b2e9@haskell.org> References: <046.c2cf60b9bc80ad55913117a33e63b2e9@haskell.org> Message-ID: <061.50ef07b0ab8e5e83d69e2ff4f483fc26@haskell.org> #9765: Strange behavior of GC under ghci -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by remdezx): @rwbarton, thanks for explaining the difference. I didn't know that! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 08:36:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 08:36:31 -0000 Subject: [GHC] #9741: Interpreter stack checks are not quite right In-Reply-To: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> References: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> Message-ID: <061.c9b25321d9587be7d727c9c3fb7b3660@haskell.org> #9741: Interpreter stack checks are not quite right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Oh, and the reason you have the debug RTS in your compiler is because `-ticky` implies `-debug`. Incidentally this is probably slowing down your builds quite a lot, so you might want to turn it off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 08:46:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 08:46:30 -0000 Subject: [GHC] #7192: Bug in -fregs-graph with -fnew-codegen In-Reply-To: <047.02bc9a5f0f505473646ec990f1bc4bac@haskell.org> References: <047.02bc9a5f0f505473646ec990f1bc4bac@haskell.org> Message-ID: <062.236180db757bdf14e9d4a10d54222b37@haskell.org> #7192: Bug in -fregs-graph with -fnew-codegen -------------------------------------+------------------------------------- Reporter: simonmar | Owner: benl Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4258 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): @jstolarek we don't want to turn it on by default due to #7679. The comment is wrong, I'll fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 08:51:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 08:51:07 -0000 Subject: [GHC] #7192: Bug in -fregs-graph with -fnew-codegen In-Reply-To: <047.02bc9a5f0f505473646ec990f1bc4bac@haskell.org> References: <047.02bc9a5f0f505473646ec990f1bc4bac@haskell.org> Message-ID: <062.bd8e67c75c69da0055ae54c39e759833@haskell.org> #7192: Bug in -fregs-graph with -fnew-codegen -------------------------------------+------------------------------------- Reporter: simonmar | Owner: benl Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4258 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:17 simonmar]: > The comment is wrong, I'll fix it. Please don't. I'll fix it. I'm just working on that code in DynFlags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 09:47:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 09:47:42 -0000 Subject: [GHC] #9776: -frule-check flag not recognized without parameter Message-ID: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> #9776: -frule-check flag not recognized without parameter -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Incorrect than a day) | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ $ ghc Foo.hs -frule-check ghc: on the commandline: unrecognised flag: -frule-check Usage: For basic information, try the `--help' option. }}} That error message is confusing. `-frule-check` is a valid flag, it's just being used incorrectly. It should be followed by a parameter: {{{ $ ghc Foo.hs -frule-check ruleFoo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 09:57:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 09:57:24 -0000 Subject: [GHC] #9776: -frule-check flag not recognized without parameter In-Reply-To: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> References: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> Message-ID: <063.38153b5ce37b024b36ad8a78a511ec5c@haskell.org> #9776: -frule-check flag not recognized without parameter -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) warning at compile-time | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): As a side note: this is clearly a debugging flag. Perhaps we should change its name to `-ddump-rule-check`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 10:14:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 10:14:36 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver Message-ID: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Other than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I bumped into two small issues with `-msse` and `-msse4.2` flags: 1. GHC accepts any flag of the form `-msseX.Y`, eg. `-msse3.14`. I think we should validate numbers passed by the user or - even better - pre- define a set of allowed `-msse` flags. Currently we have this definition: {{{ Flag "msse" (versionSuffix (\maj min d -> d{ sseVersion = Just (maj, min) })) }}} 2. A direct consequence of above definition is that bash command-line auto-completion does not suggest `-msse4.2` flag. This is somewhat related to Austin's Phab:D165 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 11:49:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 11:49:40 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.a058aa8ea3e1aef7dc127b73c3a82884@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by gintas: Old description: > The Windows build over here spews a bunch of errors during the build like > the ones below. All of them seem to be related to hsc2hs. The errors do > not the build for some reason, so the problem is not critical, but we > should look into what's going on here. > > Note that the errors are indeterministic and the set of files affected > varies between builds. > > Examples: > > {{{ > ghctrace.2/3.log:Failed to remove file libraries/base/dist- > install/build/System/CPUTime_hsc_make.exe; error= DeleteFile > "libraries/base/dist-install/build/System/CPUTime_hsc_make.exe": > permission denied (Access is denied.) > ghctrace.2/4.log:Failed to remove file libraries/hpc/dist- > boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile > "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": > permission denied (Access is denied.) > ghctrace.2/4.log:Failed to remove file > compiler/stage2/build/Fingerprint_hsc_make.exe; error= DeleteFile > "compiler/stage2/build/Fingerprint_hsc_make.exe": permission denied > (Access is denied.) > ghctrace.3/1.log:Failed to remove file libraries/hpc/dist- > boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile > "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": > permission denied (Access is denied.) > ghctrace.3/4.log:Failed to remove file libraries/old-time/dist- > install/build/System/Time_hsc_make.exe; error= DeleteFile "libraries/old- > time/dist-install/build/System/Time_hsc_make.exe": permission denied > (Access is denied.) > ghctrace.3/5.log:Failed to remove file libraries/Win32/dist- > install/build/Graphics/Win32/GDI/Pen_hsc_make.exe; error= DeleteFile > "libraries/Win32/dist-install/build/Graphics/Win32/GDI/Pen_hsc_make.exe": > permission denied (Access is denied.) > }}} New description: The Windows build over here spews a bunch of errors during the build like the ones below. All of them seem to be related to hsc2hs. The errors do not break the build for some reason, so the problem is not critical, but we should look into what's going on here. Note that the errors are indeterministic and the set of files affected varies between builds. Examples: {{{ ghctrace.2/3.log:Failed to remove file libraries/base/dist- install/build/System/CPUTime_hsc_make.exe; error= DeleteFile "libraries/base/dist-install/build/System/CPUTime_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file compiler/stage2/build/Fingerprint_hsc_make.exe; error= DeleteFile "compiler/stage2/build/Fingerprint_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/1.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/4.log:Failed to remove file libraries/old-time/dist- install/build/System/Time_hsc_make.exe; error= DeleteFile "libraries/old- time/dist-install/build/System/Time_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/5.log:Failed to remove file libraries/Win32/dist- install/build/Graphics/Win32/GDI/Pen_hsc_make.exe; error= DeleteFile "libraries/Win32/dist-install/build/Graphics/Win32/GDI/Pen_hsc_make.exe": permission denied (Access is denied.) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 12:07:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 12:07:51 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.0688088e71d9c7b0a72cfbdec4b38e1e@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): Looks like this is an old issue, all the way back from 2006, see here: http://web.archiveorange.com/archive/v/j7U5ds4Ozu7dvDiQLdtl The code that spews the error is already trying to work around the issue, but fails, it just does not break the build process. On the bright side, this particular error is not harmful, the outcome is just that a temporary file does not get deleted. Relevant code: {{{ -- delay the cleanup of generated files until the end; attempts to -- get around intermittent failure to delete files which has -- just been exec'ed by a sub-process (Win32 only.) finallyRemove :: FilePath -> IO a -> IO a finallyRemove fp act = bracket_ (return fp) (const $ noisyRemove fp) act where noisyRemove fpath = catch (removeFile fpath) (\ e -> hPutStrLn stderr ("Failed to remove file " ++ fpath ++ "; error= " ++ show e)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 12:11:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 12:11:18 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.7b251456e9290291d4d0270234b658a8@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: Phab:D444 | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed Comment: The main chunk of work on this has been done in 303776ab1ff8e192fe42374c8547b7c77305796e There is still some work to do [https://www.haskell.org/pipermail/ghc- devs/2014-November/007169.html as described on ghc-devs]. Nevertheless I'm closing this ticket as fixed because issues raised here have been addressed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 12:15:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 12:15:27 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.d17406cb7b7512eff08ede55c00c43be@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: Phab:D444 | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: jstolarek => * status: closed => new * resolution: fixed => Old description: > Sections 4.20 (Flag reference) and 4.10.2 (-f*: platform-independent > flags) of the User Guide could use some updating: > > - `-floopification` is mentioned in 4.20 but not in 4.10.2 (which, > sadly, is my fault), > - Section 4.10.2 says: "These flags turn on and off individual > optimisations. They are normally set via the -O options (...) The flags > below are off by default, except where noted below." Does the last > sentence mean they are on by default for `-O` or that they are enabled > even with `-O0` (which is the default optimisation level)? > - What is the default value of `-fmax-simplifier-iterations`? > - 4.20 mentions `-fmax-simplifier-iterations`, `-fmax-relevant- > bindings` and `-fmax-worker-args` but only the first one is described in > 4.10.2 > > I suspect there are more inconsistencies. New description: These flags are currently completely missing from the User's Guide: ? -fbuilding-cabal-package ? -fflat-cache ? -fhpc-no-auto ? -fkill-absence ? -fkill-one-shot ? -fsimple-list-literals ? -fspecialise-aggressively ? -fuse-rpaths ? -fspec-constr-recursive ? -ffloat-lam-args ? -ffloat-all-lams If you can provide description for any of these flags please edit flags.xml and using.xml. Following flags are listed in Flag Reference section (4.19) with a brief one sentence description but they don't have a detailed description in section 4.10 (using.xml): ? -fcall-arity ? -funfolding-fun-discount ? -funfolding-dict-discount ? -funfolding-keeness-factor ? -frule-check (see #9776) Following flags have a detailed description but it is confusing: ? -fdo-eta-reduction ? -fdo-lambda-eta-expansion Following flags have a description but it is too brief. We should have more details: ? -fdicts-cheap ? -fdicts-strict ? -fdmd-tx-dict-sel ? -fmax-inline-memcpy-insns ? -fmax-inline-memset-insns ? -fmax-worker-args ? -fno-opt-coercion ? -fno-pre-inlining ? -fsimplifier-phases ? -fspec-constr-threshold ? -fspec-constr-count ? -fstrictness-before For these flags Flag Reference section provides the description of their -fno-* version: ? -fembed-manifest ? -fgen-manifest ? -fghci-history ? -fghci-sandbox ? -fpre-inlining ? -fprint-bind-contents ? -fprof-count-entries ? -fshared-implib This seems to go against our convention of describing the flags. Should we revert to desribing their normal version (ie. ones that enable something, not disable)? We should also make sure that documentation of remaining flags is up to date, especially the -d* ones. -- Comment: After some thought perhaps it's not a good idea to close this ticket. I'm changing the description to contain a list of flags to document and reopening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 12:22:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 12:22:52 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.25d0068de2989ae5f6a0839c71120c03@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): I'd prefer an enumeration data type for enumerating the supported SSE versions; there aren't that many SSE versions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 13:06:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 13:06:11 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.99632db3ba4453e55e26e9895b6728b9@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 13:30:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 13:30:56 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.1dc0ae94934e806dfafb76d2cb20970e@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: 9614 GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 13:33:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 13:33:47 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken In-Reply-To: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> References: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> Message-ID: <062.a28170f62a5954980a76e6313d74c040@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 9421 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) * milestone: => 7.10.1 Comment: I set milestone to 7.10 (I hope that makes sense). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 14:01:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 14:01:15 -0000 Subject: [GHC] #9774: Type error messages containing calls to assert could be prettier. In-Reply-To: <044.c71fc52331933a746aaeda39862422da@haskell.org> References: <044.c71fc52331933a746aaeda39862422da@haskell.org> Message-ID: <059.94808638d50948bbccb261879c6e83f4@haskell.org> #9774: Type error messages containing calls to assert could be prettier. -------------------------------------+------------------------------------- Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0f930ba2039e28d0083780a58adb37ff01a92019/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0f930ba2039e28d0083780a58adb37ff01a92019" Move expansion of 'assert' from renamer to typechecker This improves error messages when there is a type error, fixing Trac #9774 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 14:22:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 14:22:57 -0000 Subject: [GHC] #8308: Resurrect ticky code for counting constructor arity In-Reply-To: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> References: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> Message-ID: <063.ae0f240246cbe41c41f5e0e6471686c5@haskell.org> #8308: Resurrect ticky code for counting constructor arity -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: mlen Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by mlen): * owner: => mlen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 14:27:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 14:27:29 -0000 Subject: [GHC] #9774: Type error messages containing calls to assert could be prettier. In-Reply-To: <044.c71fc52331933a746aaeda39862422da@haskell.org> References: <044.c71fc52331933a746aaeda39862422da@haskell.org> Message-ID: <059.e776522596671fc92f0fa18fbe64a011@haskell.org> #9774: Type error messages containing calls to assert could be prettier. -------------------------------------+------------------------------------- Reporter: josef | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | typecheck/should_fail/T9774 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T9774 * resolution: => fixed Comment: Good idea, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 15:42:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 15:42:31 -0000 Subject: [GHC] #3064: Very long compile times with type functions In-Reply-To: <046.2a7b2611764311f7357001c522d303b9@haskell.org> References: <046.2a7b2611764311f7357001c522d303b9@haskell.org> Message-ID: <061.a8e12c144d041fda140807a25d981298@haskell.org> #3064: Very long compile times with type functions -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: low | closed Component: Compiler (Type checker) | Milestone: 7.6.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 6.10.1 Type of failure: Compile-time performance bug | Keywords: Test Case: perf/compiler/T3064 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"096b7e664351d102cc9e15f3aa226a976af5dae2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="096b7e664351d102cc9e15f3aa226a976af5dae2" Switch off lazy flattening (fix Trac #3064) See Note [Lazy flattening] in TcFlatten. Lazy flattening was an apparently good idea which actually made the type inference engine go a LOTS slower in T3064. So I switched it off again. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 15:48:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 15:48:02 -0000 Subject: [GHC] #9771: Excessive memory usage compiling T3064 In-Reply-To: <042.84d31aae5dbeacb6c2c61f31caf478e6@haskell.org> References: <042.84d31aae5dbeacb6c2c61f31caf478e6@haskell.org> Message-ID: <057.57bcc18d4e357ca82d0c74dd4f1ba108@haskell.org> #9771: Excessive memory usage compiling T3064 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I believe I have fixed the long compile time on T3064. I've re-enabled: {{{ commit c79cbacb6d9161c529ac13685ff29ac058a3ebfa Author: Simon Peyton Jones Date: Thu Nov 6 15:46:11 2014 +0000 Re-enable T3064, which works now testsuite/tests/perf/compiler/all.T | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 15:52:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 15:52:18 -0000 Subject: [GHC] #9011: panic - interactiveUI:setBuffering2 In-Reply-To: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> References: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> Message-ID: <059.554b16a820016ce548530bb5df039a83@haskell.org> #9011: panic - interactiveUI:setBuffering2 -------------------------------------+---------------------------------- Reporter: irneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Comment (by HairyDude): Got this in 7.6.3 (Linux Mint 17) with an easy reproduction method: 1. `mkdir tmp && cd tmp` 1. `cabal sandbox init` 1. `echo 'module Test where main = putStrLn "Hello world"' > Test.hs` 1. `GHC_PACKAGE_PATH=.cabal-sandbox/x86_64-linux-ghc-7.6.3-packages.conf.d runghc Test.hs` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 16:45:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 16:45:43 -0000 Subject: [GHC] #9778: Namespace collision detection for promoted types Message-ID: <047.2d273cde6d3a8c2e3d4c41837bafa1a1@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In the following example {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where data Nat = Z | S Nat data S foo :: S n -> S n foo = id }}} GHC displays the error {{{ Foo.hs:12:8: ?S? is applied to too many type arguments In the type signature for ?foo?: foo :: S n -> S n Failed, modules loaded: none. }}} Although it's clear in my example where the problem is, this example was distilled from a case where I imported module1 with type `S` defined and module2 with the promoted type `S`, which is what I was trying to use. Can we get namespace collision detection instead? Something like: {{{ Foo.hs:9:15 Ambiguous occurence ?S? It could refer to either Foo.S defined at Foo.hs:7:1 or to the promoted constructor S defined at Foo.hs:5:16 Use 'S to refer to the promoted constructor. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 17:02:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 17:02:07 -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.8ef00313f445384fcbd032c7d651b1d7@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kosmikus): But what if you mean the datatype `S` and not the promoted constructor? If you report an ambiguity error, we would need a way to disambiguate the other way as well, and we currently cannot. I guess the kind error you're getting now could in addition include a hint that there's an ambiguity, though, something like {{{ Foo.hs:12:8: ?S? is applied to too many type arguments In the type signature for ?foo?: foo :: S n -> S n (Hint: did you mean the promoted constructor 'S?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 17:04:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 17:04:27 -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.8c605eaf896c47613ee28b3450f7250a@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > In the following example > {{{#!hs > {-# LANGUAGE DataKinds #-} > > module Foo where > > data Nat = Z | S Nat > > data S > > foo :: S n -> S n > foo = id > }}} > > GHC displays the error > > {{{ > Foo.hs:12:8: > ?S? is applied to too many type arguments > In the type signature for ?foo?: foo :: S n -> S n > Failed, modules loaded: none. > }}} > Although it's clear in my example where the problem is, this example was > distilled from a case where I imported module1 with type `S` defined and > module2 with the promoted type `S`, which is what I was trying to use. > Can we get namespace collision detection instead? Something like: > > {{{ > Foo.hs:9:15 > Ambiguous occurence ?S? > It could refer to either Foo.S defined at Foo.hs:7:1 > or to the promoted constructor S defined at > Foo.hs:5:16 > Use 'S to refer to the promoted constructor. > }}} New description: In the following example {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where data Nat = Z | S Nat data S foo :: S n -> S n foo = id }}} GHC displays the error {{{ Foo.hs:12:8: ?S? is applied to too many type arguments In the type signature for ?foo?: foo :: S n -> S n Failed, modules loaded: none. }}} Of course this code compiles without the definition of `data S`. Without namespace collision detection, it is easy to have working code, and then import a module which breaks the code. For example, I made this request after I imported Module1 with type `S` defined and Module2 with the promoted type `S`, which is what I was trying to use. Can we get namespace collision detection instead? I'm proposing something like: {{{ Foo.hs:9:15 Ambiguous occurence ?S? It could refer to either Foo.S defined at Foo.hs:7:1 or to Foo.'S promoted from the constructor defined at Foo.hs:5:16 or to `Bar.'S` promoted from the constructor defined at Bar.hs:line#:char# or to ... Use 'S to refer to promoted constructors. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 17:07:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 17:07:16 -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.21a89c3e6006e89d6fce01a115cb824d@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): @kosimus I see your point. I think your suggestion would certainly be an improvement over the current error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 22:07:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 22:07:07 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.394b73e11a3509d1db22f21003c09e65@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): I have a fix for this in https://phabricator.haskell.org/D452. However, I just realized that I forgot to create a specific option for this warning. But does this even need an option?? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 22:18:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 22:18:35 -0000 Subject: [GHC] #7692: ghci -ignore-package base lets the impossible happen In-Reply-To: <046.1cdf4a540511aa31fb58d0b973b732a2@haskell.org> References: <046.1cdf4a540511aa31fb58d0b973b732a2@haskell.org> Message-ID: <061.76e4f050b89fa3797f22ca87b0c614e2@haskell.org> #7692: ghci -ignore-package base lets the impossible happen -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This has been fixed somewhere along the way: {{{ $ ghci -ignore-package base GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Top level: Failed to load interface for ?Prelude? Use -v to see a list of the files searched for. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 22:20:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 22:20:15 -0000 Subject: [GHC] #7531: after manualy installing array-0.4.0.1 In-Reply-To: <044.b2b929ca54bdaf76af0761ef895fbe05@haskell.org> References: <044.b2b929ca54bdaf76af0761ef895fbe05@haskell.org> Message-ID: <059.9efbff047adf1785c5b5c66015c8f6d6@haskell.org> #7531: after manualy installing array-0.4.0.1 -----------------------------------------+--------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Package system | Version: 7.6.1 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7692 Differential Revisions: | -----------------------------------------+--------------------------- Changes (by thomie): * related: => #7692 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 22:36:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 22:36:36 -0000 Subject: [GHC] #9011: panic - interactiveUI:setBuffering2 In-Reply-To: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> References: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> Message-ID: <059.7443fac49fdc2b1958fe9d992e01566a@haskell.org> #9011: panic - interactiveUI:setBuffering2 -------------------------------------+---------------------------------- Reporter: irneb | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7692 Differential Revisions: | -------------------------------------+---------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #7692 Comment: The bug of the confusing panic message has been fixed, somewhere between version 7.6.3 and version 7.8.3. Repeating the steps from comment:5, or just `ghci -ignore-package base`, now prints: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Top level: Failed to load interface for ?Prelude? Use -v to see a list of the files searched for. }}} @irneb. I'm sorry you ran into this problem. I understand you tried solving the problem by installing libffi from looking at #3144, but that is a 6 year ticket. For anyone else running into problems like this: try installng the most recent version of GHC first, and start over with new `.ghc` and `.cabal` directories in your home directory. Also make sure there is no strange GHC_PACKAGE_PATH variable in your shell environment (maybe from a previous installation). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 23:30:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 23:30:20 -0000 Subject: [GHC] #9009: Confusing error message when loading package with TH In-Reply-To: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> References: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> Message-ID: <063.ddb1157fe7083b223f5e74b887d6ca00@haskell.org> #9009: Confusing error message when loading package with TH -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.8.2 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): @jstolarek is this still a problem? What are the steps needed to reproduce it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 23:48:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 23:48:32 -0000 Subject: [GHC] #8992: Instructions for using gdb with GHC on Windows In-Reply-To: <045.5da142d588020e3fc1397add8a636ef7@haskell.org> References: <045.5da142d588020e3fc1397add8a636ef7@haskell.org> Message-ID: <060.d21b661c7744dfe43cd74b489a10d250@haskell.org> #8992: Instructions for using gdb with GHC on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: Documentation | Keywords: msys,msys2 Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 6 23:58:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Nov 2014 23:58:08 -0000 Subject: [GHC] #7603: Bad magic in static (FFI) object (7.6.1 for x86_64-apple-darwin) In-Reply-To: <047.ee5946db03309bc549af9d62a006551f@haskell.org> References: <047.ee5946db03309bc549af9d62a006551f@haskell.org> Message-ID: <062.51533bf570a948367241c99216dd22a5@haskell.org> #7603: Bad magic in static (FFI) object (7.6.1 for x86_64-apple-darwin) -------------------------------------+------------------------------------- Reporter: morabbin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: #7628 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * related: => #7628 Comment: The error message has been improved in #7628. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 00:05:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 00:05:19 -0000 Subject: [GHC] #8626: Bad magic. Expected: feedfacf, got: feedface In-Reply-To: <044.81de4f3ab57a9e527b78bf9c28e8e7c1@haskell.org> References: <044.81de4f3ab57a9e527b78bf9c28e8e7c1@haskell.org> Message-ID: <059.6ff66a65247d047671853ae94dc6b541@haskell.org> #8626: Bad magic. Expected: feedfacf, got: feedface -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #7603, #7628 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => invalid * related: => #7603, #7628 Comment: Any "bad magic" is most likely a result of mixing 32 bit and 64 bit objects files, see #7603. The error message got much improved in #7628 (GHC 7.8). Closing as not a ghc problem. @guest please reopen if you still encounter problems when using GHC 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 00:12:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 00:12:10 -0000 Subject: [GHC] #8986: GHC panic while installing distributive library on Mac OS X Mavericks In-Reply-To: <046.b8996dc60dcf52ba9ff88c219d35b963@haskell.org> References: <046.b8996dc60dcf52ba9ff88c219d35b963@haskell.org> Message-ID: <061.3e2ad364168e3beb0223a829d3adfb22@haskell.org> #8986: GHC panic while installing distributive library on Mac OS X Mavericks -------------------------------------+------------------------------------- Reporter: mvanier | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #7628,#8626,#7603 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid * related: => #7628,#8626,#7603 Comment: Any "bad magic" panics are most likely a result of mixing 32 bit and 64 bit objects files, see #7603. The error message got much improved in #7628 (GHC 7.8). Closing as not a ghc problem. @mvanier please reopen if you still encounter problems (after testing with GHC 7.8.3 if possible). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 00:34:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 00:34:03 -0000 Subject: [GHC] #8981: ghc-pkg complains about missing haddock interface files In-Reply-To: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> References: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> Message-ID: <067.4e66dca596e7c760825c0f7d881cd80a@haskell.org> #8981: ghc-pkg complains about missing haddock interface files -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.1 Component: ghc-pkg | Keywords: ghc-pkg Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * component: Compiler => ghc-pkg Comment: I have the same problem on Ubuntu, with Haskell platform 2014.02 installed. {{{ # First remove .cabal and .ghc, then: $ cabal install random ... $ ghc-pkg check Warning: haddock-interfaces: /home/thomas/.cabal/share/doc/x86_64-linux- ghc-7.8.3/random-1.1/html/random.haddock doesn't exist or isn't a file Warning: haddock-html: /home/thomas/.cabal/share/doc/x86_64-linux- ghc-7.8.3/random-1.1/html doesn't exist or isn't a directory }}} Using `cabal install random --enable-documentation` instead makes the warnings go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 00:41:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 00:41:55 -0000 Subject: [GHC] #9268: internal error: evacuate(static): strange closure type -385875968 In-Reply-To: <043.1b0896c34329d32a2c2042b8706f86ba@haskell.org> References: <043.1b0896c34329d32a2c2042b8706f86ba@haskell.org> Message-ID: <058.137d14c886b968ff905a2ed6fdfd5aad@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 -------------------------------------+------------------------------------- Reporter: brbr | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: 9439 Test Case: | Related Tickets: #8976 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 00:47:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 00:47:41 -0000 Subject: [GHC] #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters In-Reply-To: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> References: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> Message-ID: <059.6e758d9f78478e4b847fb89aac58e26f@haskell.org> #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters -------------------------------------+------------------------------------- Reporter: slomo | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8976 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * component: Compiler => Driver * related: => #8976 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 01:03:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 01:03:41 -0000 Subject: [GHC] #8623: Strange slowness when using async library with FFI callbacks In-Reply-To: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> References: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> Message-ID: <065.309522837d13ba21da9e889706f32175@haskell.org> #8623: Strange slowness when using async library with FFI callbacks -------------------------------------+------------------------------------- Reporter: | Owner: simonmar JohnWiegley | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 01:38:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 01:38:56 -0000 Subject: [GHC] #9100: Cannot build crypto-pubkey with GHC 7.8.2 and profiling In-Reply-To: <050.9608f139c137bdcc7b58020f3ff0d914@haskell.org> References: <050.9608f139c137bdcc7b58020f3ff0d914@haskell.org> Message-ID: <065.ee1fe2c4da67481b398476431c4d56ee@haskell.org> #9100: Cannot build crypto-pubkey with GHC 7.8.2 and profiling -------------------------------------+------------------------------------- Reporter: | Owner: JohnWiegley | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: I can not reproduce this issue on Ubuntu Linux. I tried the following steps. First, set `library-profiling: True` in .cabal/config. Then: {{{ $ git clone http://github.com/vincenthz/hs-crypto-pubkey $ cd hs-crypto-pubkey $ cabal sandbox init $ cabal install --only-dependencies $ cabal configure --disable-split-objs --enable-library-profiling --enable-shared --enable-library-vanilla --enable-executable-dynamic $ cabal build }}} The build succeeds. @JohnWiegley can you try again with GHC 7.8.3 please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 01:46:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 01:46:13 -0000 Subject: [GHC] #8975: Troubling build warning with GHC 7.8.1 on Mavericks In-Reply-To: <050.6c30c380c8c9fe6f1e3c389f821c0db6@haskell.org> References: <050.6c30c380c8c9fe6f1e3c389f821c0db6@haskell.org> Message-ID: <065.e6a7e36b7ae1383f1ada86dddc6448ca@haskell.org> #8975: Troubling build warning with GHC 7.8.1 on Mavericks --------------------------------------+---------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7373 Differential Revisions: | --------------------------------------+---------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => duplicate * related: => #7373 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 01:47:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 01:47:41 -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.faa9021bedfca60a224cb732265e483d@haskell.org> #7373: When building GHC: Failed to load interface for `GHC.Fingerprint' -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Driver | Version: 7.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8975 Test Case: | driver/T7373 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Core Libraries => Driver * related: => #8975 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 01:59:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 01:59:24 -0000 Subject: [GHC] #8962: compile hang and memory blowup when using profiling and optimization In-Reply-To: <044.a9159e5a0f1565df240a29d6f9f6e9a9@haskell.org> References: <044.a9159e5a0f1565df240a29d6f9f6e9a9@haskell.org> Message-ID: <059.48e952b3ad2d1ac080dc3c8265fa533c@haskell.org> #8962: compile hang and memory blowup when using profiling and optimization -------------------------------------+------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Compiling your example with `ghc -O2 -prof -fprof-auto-calls Woo.hs` finished successfully in less than a second on my machine, using GHC 7.8.3. Please reopen if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 02:26:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 02:26:02 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.7206a90062bf09b1bf957cbfbeb642f2@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D452 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D452 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 02:45:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 02:45:34 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.1562f250d8fbdbd2b06e9d52d499cfc9@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: AlainODea Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Easy (less than 1 time crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => fixed Comment: Replying to [comment:9 kgardas]: > so feel free to close this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 02:51:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 02:51:56 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.d5423db055f0e61b81af6a82c5e09e9f@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 02:52:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 02:52:53 -0000 Subject: [GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults In-Reply-To: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> References: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> Message-ID: <065.80c808417d17876bb75586972c77fcb0@haskell.org> #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------------------+------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------ Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 03:06:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 03:06:26 -0000 Subject: [GHC] #8904: haddock displays GHC.Types.Coercible as a datatype In-Reply-To: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> References: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> Message-ID: <061.c3a15c9b8b4eb8de5259953d931daa80@haskell.org> #8904: haddock displays GHC.Types.Coercible as a datatype -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Documentation bug is still present. Link to the documentation of [http://haskell.inf.elte.hu/docs/latest/html/libraries/ghc-prim-0.3.1.0 /GHC-Types.html#t:Coercible GHC.Types.Coercible]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 03:25:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 03:25:21 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.1e67dfa47abab13814fda2bf8b2843fb@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 03:31:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 03:31:01 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended Message-ID: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | Documentation bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- The Building/Preparation/MacOSX page suggests using Darin Morrison's brewtap to install ghc using Homebrew: 3. Use one of Fink, MacPorts or Brew. If using brew, we strongly recommend using Darin's ?brewtap for ghc Darin's brewtap, however, is deprecated: https://github.com/darinmorrison/homebrew-haskell For the most part, it seems that the default homebrew install works correctly, but `./configure` fails because Happy is not installed. We should either (1) remove the recommendation to use Homebrew or (2) explain how to install all of the necessary components to build GHC. (I couldn't figure out how to install Happy using Homebrew's cabal-install formula, so I used the GHC Platform instead.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 03:50:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 03:50:29 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.856848efd590d597ba81f490d34a54f5@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ihmccreery): I've changed the wiki as best I can, with the knowledge I have, but my changes should probably be reviewed by someone who knows more than me: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX?action=diff&version=10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 03:52:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 03:52:23 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.28b8dd06e90b6255b596ccc1ab3b8f89@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ihmccreery): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 05:16:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 05:16:10 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.037be4ff64eaf679318306f3ab72ea85@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * status: new => closed * resolution: => fixed Comment: your changes looked good, I added some additional cleanup. Though theres a chance i've over looked something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 06:56:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 06:56:16 -0000 Subject: [GHC] #9009: Confusing error message when loading package with TH In-Reply-To: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> References: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> Message-ID: <063.ce5f956639b5ce01f070a7b4411b35a5@haskell.org> #9009: Confusing error message when loading package with TH -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.8.2 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Thomie, I haven't tried this with HEAD. With 7.8.3 the problem is of course there. Here are steps to reproduce: 1. `cabal get singletons` 2. `cd singletons-1.0` 3. edit `singletons.cabal` and remove line 98 (`Data.Singletons.Single.Monad` from `other-modules` section) 4. `cabal install` 5. `ghc Foo.hs` where `Foo.hs` contains: {{{#!hs {-# LANGUAGE TemplateHaskell, KindSignatures, DataKinds, TypeFamilies, ExistentialQuantification #-} module Foo where import Data.Singletons.TH $(promote [d| data N = Z | S N |]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 08:05:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 08:05:04 -0000 Subject: [GHC] #8904: haddock displays GHC.Types.Coercible as a datatype In-Reply-To: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> References: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> Message-ID: <061.8e883c7837152569a830348ba80dfab7@haskell.org> #8904: haddock displays GHC.Types.Coercible as a datatype -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8894 Test Case: | Blocking: | Differential Revisions: Phab:D300 | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: => Phab:D300 * related: => #8894 Comment: I know. I believe that #8894 / Phab:D300 might fix this, but there is a problem that requires someone with knowledge of codegen and linker stuff to look at it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 08:29:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 08:29:52 -0000 Subject: [GHC] #9780: dep_orphs in Dependencies redundantly records type family orphans Message-ID: <045.8bb223632e43c545d555772c72d364f6@haskell.org> #9780: dep_orphs in Dependencies redundantly records type family orphans -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, there is a comment on `dep_orphs` claiming this: {{{ , dep_orphs :: [Module] -- ^ Orphan modules (whether home or external pkg), -- *not* including family instance orphans as they -- are anyway included in 'dep_finsts' }}} However, it is not difficult to discover that this is not true: {{{ [ezyang at hs01 ghc-quick]$ cat A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a :: * [ezyang at hs01 ghc-quick]$ cat B.hs {-# LANGUAGE TypeFamilies #-} module B where import A type instance F Int = Bool [ezyang at hs01 ghc-quick]$ cat C.hs module C where import B [ezyang at hs01 ghc-quick]$ inplace/bin/ghc-stage2 --show-iface C.hi | grep orphans orphans: GHC.Base GHC.Float B }}} I'm not sure if the comment or the implementation is wrong. Certainly `TcRnDriver` would not work if we removed type family orphans from the list, because we only currently load `imp_orphans` and not `imp_finsts`. This change occured in this commit: {{{ commit 8f212ab5307434edf92c7d10fe0df88ccb5cd6ca Author: Simon Peyton Jones Date: Thu May 26 14:30:15 2011 +0100 Rejig the way in which generic default method signatures are checked - Check GenericSig in tcClassSigs, along with TypeSig - Add the generic default methods to the type envt - Look them up via tcLookupId in TcClassDcl.tcDefMeth Much nicer! diff --git a/compiler/typecheck/TcRnDriver.lhs b/compiler/typecheck/TcRnDriver.lhs index 2542ad3..5aa6959 100644 --- a/compiler/typecheck/TcRnDriver.lhs +++ b/compiler/typecheck/TcRnDriver.lhs @@ -245,7 +245,6 @@ tcRnImports hsc_env this_mod import_decls -- interfaces, so that their rules and instance decls will be -- found. ; loadOrphanModules (imp_orphs imports) False - ; loadOrphanModules (imp_finsts imports) True -- Check type-familily consistency ; traceRn (text "rn1: checking family instance consistency") }}} When did we start adding type family orphans to the list? This commit is to blame (it states that modules with type family orphans are orphans, which means that it will get added to orphan module list in `RnNames` when we import the interface: {{{ commit 98a642cf29781ebd33994a4ecbea6ef07f89bbed Author: Simon Peyton Jones Date: Tue Jan 3 10:35:08 2012 +0000 Major refactoring of CoAxioms @@ -619,7 +620,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls mi_exp_hash = export_hash, mi_orphan_hash = orphan_hash, mi_flag_hash = flag_hash, - mi_orphan = not (null orph_rules && null orph_insts + mi_orphan = not ( null orph_rules + && null orph_insts + && null orph_fis && null (ifaceVectInfoVar (mi_vect_info iface0))), mi_finsts = not . null $ mi_fam_insts iface0, mi_decls = sorted_decls, @@ -631,12 +634,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls this_mod = mi_module iface0 dflags = hsc_dflags hsc_env this_pkg = thisPackage dflags - (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0) - (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0) - -- See Note [Orphans] in IfaceSyn - -- ToDo: shouldn't we be splitting fam_insts into orphans and - -- non-orphans? - fam_insts = mi_fam_insts iface0 + (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0) + (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0) + (non_orph_fis, orph_fis) = mkOrphMap ifFamInstOrph (mi_fam_insts iface0) fix_fn = mi_fix_fn iface0 }}} I think this is probably a legitimate optimization (keeps interface file smaller), and we try to put it back into effect. The only downside is we'll try to load in the entire `mi_fam_insts` list (mostly harmless sense redundant requests on that front will hit the cache); also, it's more elegant if mi_orph describes orphanness over all orphans. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 09:11:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 09:11:15 -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.09329ef4abc5c0c5061da5e056434f78@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Kosmikus is right. Moreover, it's very common to say {{{ data T = T Int f :: T -> T f (T x) = T (x+1) }}} where the type and the data constructor deliberately share a name. That has to work. So in general terms, Kosmikus's suggestion of a hint is probably the way to go. However in this example, the hint is positively misleading. You say that "This code compiles without the definition of `data S`" but that's not true: {{{ T9778.hs:9:8: Expected a type, but ?S n? has kind ?Nat? In the type signature for ?foo?: foo :: S n -> S n }}} So suggesting to use the data constructor instead is not helpful. I suppose if you had {{{ foo :: Proxy (S n) -> Proxy (S n) }}} ''then'' the hint would make sense. But now thing are getting quite complicated! I'm concerned that we might make matters worse instead of better. Suggestions welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 09:19:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 09:19:08 -0000 Subject: [GHC] #9781: Make list monad operations fuse Message-ID: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> #9781: Make list monad operations fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D455 -------------------------------------+------------------------------------- We like to think that `do {x <- xs; y <- f x ; return g y}` is the same as `[g y | x <- xs, y <- f x]`, but the former does not fuse nearly as well. Let's fix that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 11:33:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 11:33:23 -0000 Subject: [GHC] #9591: Add custom "Wiki" field in Trac In-Reply-To: <048.abc646341c4c6a2ec973239fa3b2d045@haskell.org> References: <048.abc646341c4c6a2ec973239fa3b2d045@haskell.org> Message-ID: <063.0ba419a81cff205fc7668c7110adc627@haskell.org> #9591: Add custom "Wiki" field in Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Trac & Git | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Bump. Any chance to add this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 12:25:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 12:25:06 -0000 Subject: [GHC] #8947: Depending on hint/ghc API fixes the binary version I can use In-Reply-To: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> References: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> Message-ID: <057.5cb422d85b20f0f8e2756526614b14fa@haskell.org> #8947: Depending on hint/ghc API fixes the binary version I can use -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 12:27:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 12:27:19 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.d3cf5853d69ff57d4f0c6b0415af2c93@haskell.org> #8949: switch -msse2 to be on by default -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: x86 Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: Other => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 12:38:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 12:38:23 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.c6448c2eef1c6bfa46449753ac9a6529@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------------+------------------------------ Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.8.1-rc2 Resolution: | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------ Changes (by thomie): * cc: hvr (added) * status: new => infoneeded * component: Compiler => GHCi Comment: @Ansible is this still a problem? Have you tried with 7.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 12:43:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 12:43:36 -0000 Subject: [GHC] #8887: Double double assignment in optimized Cmm on SPARC In-Reply-To: <046.7dd6ce694dc9c9f0e18236436c35d4a8@haskell.org> References: <046.7dd6ce694dc9c9f0e18236436c35d4a8@haskell.org> Message-ID: <061.d89da54827a2f10e94ed3c0c85ca484d@haskell.org> #8887: Double double assignment in optimized Cmm on SPARC -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: sparc Operating System: Solaris | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 13:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 13:32:42 -0000 Subject: [GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion In-Reply-To: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> References: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> Message-ID: <060.e46b15fed5be679aaea4252d8da086e2@haskell.org> #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"24e05f48f3a3a1130ecd5a46e3089b76ee5a2304/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="24e05f48f3a3a1130ecd5a46e3089b76ee5a2304" *Really*, really fix RTS crash due to bad coercion. Summary: My previous attempt to fix the new coercion bug introduced by my fix actually just reverted back to the *old* bug. This time it should properly handle all three size scenarios. Signed-off-by: Merijn Verstraaten Test Plan: validate Reviewers: dfeuer, austin, hvr Reviewed By: austin, hvr Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D407 GHC Trac Issues: #8089 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 13:33:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 13:33:50 -0000 Subject: [GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion In-Reply-To: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> References: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> Message-ID: <060.83dcbb5c481b56e042582cb64ab6da63@haskell.org> #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D407 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge * differential: => Phab:D407 * milestone: => 7.10.1 Comment: OK, closing *again*, for good this time hopefully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 13:34:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 13:34:36 -0000 Subject: [GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion In-Reply-To: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> References: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> Message-ID: <060.e633993e47bc12774eff4646a8ab2fee@haskell.org> #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D407 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 13:57:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 13:57:37 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.7ce87d98d41a24e7f6df2e72f3e7dbb9@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 14:08:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 14:08:32 -0000 Subject: [GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm In-Reply-To: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> References: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> Message-ID: <061.821ba4cc2b313083d0b5342c1b9b7926@haskell.org> #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: Other => Runtime performance bug * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 14:47:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 14:47:40 -0000 Subject: [GHC] #8853: Surprising mention of unboxed integers in pattern exhaustiveness warning In-Reply-To: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> References: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> Message-ID: <069.762e1c2c2e693ffa9cb98b0b2bf4569f@haskell.org> #8853: Surprising mention of unboxed integers in pattern exhaustiveness warning -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Old description: > The attached code produces this alarming warning: > > {{{ > ~/waste$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 > ~/waste$ ghc -Wall --make AlarmingPattern.hs -fforce-recomp > [1 of 1] Compiling Main ( AlarmingPattern.hs, > AlarmingPattern.o ) > > AlarmingPattern.hs:6:7: Warning: > Pattern match(es) are non-exhaustive > In an equation for ?takeFromInv?: > Patterns not matched: > (GHC.Types.I# _) (GHC.Types.I# (#x)) with #x `notElem` [0#] > Linking AlarmingPattern ... > ~/waste$ ./AlarmingPattern > AlarmingPattern: AlarmingPattern.hs:(6,7)-(7,26): Non-exhaustive patterns > in function takeFromInv > }}} New description: The attached code produces this alarming warning: {{{ ~/waste$ ghc -Wall --make AlarmingPattern.hs -fforce-recomp [1 of 1] Compiling Main ( AlarmingPattern.hs, AlarmingPattern.o ) AlarmingPattern.hs:6:7: Warning: Pattern match(es) are non-exhaustive In an equation for ?takeFromInv?: Patterns not matched: (GHC.Types.I# _) (GHC.Types.I# (#x)) with #x `notElem` [0#] Linking AlarmingPattern ... }}} The error message is alarming because it refers to unboxed integers, but the source code does not. -- Comment (by thomie): Reproducable with version 7.9.20140802. This ticket is listed on [wiki:Status/SLPJ-Tickets]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 14:51:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 14:51:41 -0000 Subject: [GHC] #7285: mkWeakMVar is non-compositional In-Reply-To: <044.e6c10f44e589834510279a56d62e7d7d@haskell.org> References: <044.e6c10f44e589834510279a56d62e7d7d@haskell.org> Message-ID: <059.0b3ab0e8bc1bb75d1525475120671afe@haskell.org> #7285: mkWeakMVar is non-compositional -------------------------------------+------------------------------------- Reporter: edsko | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * owner: => ekmett * component: Compiler => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 14:59:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 14:59:07 -0000 Subject: [GHC] #9782: Do not by default set ekmett as owner for 'Core libraries' Message-ID: <045.9a4eaf64f0d6b763bc80d89ea22b10c3@haskell.org> #9782: Do not by default set ekmett as owner for 'Core libraries' -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- And if possible, do a mass update of removing him from existing tickets: https://ghc.haskell.org/trac/ghc/query?component=Core+Libraries&owner=ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 15:05:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 15:05:01 -0000 Subject: [GHC] #8396: cleanup / refactor native code gens In-Reply-To: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> References: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> Message-ID: <060.bb4dcfe67ae1df522370fd3898e62b08@haskell.org> #8396: cleanup / refactor native code gens -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8299 , #8287 None/Unknown | ,#8272 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: feature request => task * component: Compiler (CodeGen) => Compiler (NCG) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 15:18:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 15:18:59 -0000 Subject: [GHC] #8843: Maverick GHC --make problem - linking problem In-Reply-To: <045.7aef55c0386e202f1a9a5c0da91c24b7@haskell.org> References: <045.7aef55c0386e202f1a9a5c0da91c24b7@haskell.org> Message-ID: <060.e9f740846d2f1ebdc6c8e6ef08a3faad@haskell.org> #8843: Maverick GHC --make problem - linking problem -------------------------------------+------------------------------------- Reporter: teuffy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: #4068 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #4068 Comment: @teuffy I'm sorry to hear you ran into this problem. This is however not a GHC bug, but most likely a problem with code that "is getting compiled against one iconv library, but then linked against another (incompatible) iconv library". See ticket #4068 for possible solutions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 15:31:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 15:31:56 -0000 Subject: [GHC] #8829: GHC HEAD/7.8 fails to build on Solaris 10 In-Reply-To: <046.7dcb5f6b84381ef10d096b9ada5756ce@haskell.org> References: <046.7dcb5f6b84381ef10d096b9ada5756ce@haskell.org> Message-ID: <061.8c6fa985685b26bb91e5fdabd8980f12@haskell.org> #8829: GHC HEAD/7.8 fails to build on Solaris 10 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: wontfix | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: kgardas: I added a note to [wiki:Building/Preparation/Solaris], saying to not use GCC 3.4.3, and a link back to this bug. That page recommends to use GCC 4.1.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 15:57:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 15:57:11 -0000 Subject: [GHC] #8816: Make SPARC registerised again. In-Reply-To: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> References: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> Message-ID: <061.20daf3c59bbcbf90192acdf7f4014c65@haskell.org> #8816: Make SPARC registerised again. ------------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8847 Blocking: | Related Tickets: Differential Revisions: | ------------------------------------------+--------------------------- Comment (by thomie): This may be obvious, but that default is decided in `configure.ac`: {{{ dnl ** Do an unregisterised build? dnl -------------------------------------------------------------- case "$HostArch" in i386|x86_64|powerpc|arm) UnregisterisedDefault=NO ;; *) UnregisterisedDefault=YES ;; esac }}} Last changed in commit f917eeb824cfb7143dde9b12e501d4ddb0049b65. But before adding `|sparc` to that list, at least #8847 needs to be fixed first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:15:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:15:47 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.77509a2e540dea491158dd175f464773@haskell.org> #8814: 7.8 optimizes attoparsec improperly -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #8763 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:16:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:16:16 -0000 Subject: [GHC] #7285: mkWeakMVar is non-compositional In-Reply-To: <044.e6c10f44e589834510279a56d62e7d7d@haskell.org> References: <044.e6c10f44e589834510279a56d62e7d7d@haskell.org> Message-ID: <059.6e096eed32225bfbfccde4fd349fe425@haskell.org> #7285: mkWeakMVar is non-compositional -------------------------------------+------------------------------------- Reporter: edsko | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): I've sent out a proposal for discussion on libraries@ to seek community feedback, so we can finally clear this out. In general I'm in favor of making the change, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:20:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:20:41 -0000 Subject: [GHC] #9781: Make list monad operations fuse In-Reply-To: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> References: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> Message-ID: <060.19d314d0f3e5e23e5007f0be65c03d21@haskell.org> #9781: Make list monad operations fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D455 | -------------------------------------+------------------------------------- Comment (by ekmett): I have no issues with improving fusion for do sugared lists, the question is if it is possible to achieve this change with just a libraries fix or if you need to go into the compiler. There is a lot of crazy code down in the list comprehension module that gets used to make lists fast there. It isn't clear to me how we'd lean on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:23:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:23:21 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.92bfb41c42235eca4b65afd6c033b047@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ihmccreery): Glad to have all that updated. I'm brand new to working on GHC, so I'll trust your changes re gcc & llvm. Returning to this, I'm realizing that the main issue here is that nowhere on this page does it explain that you need Happy, (and maybe other tools included in the Haskell Platform?), not just a binary of GHC, to build GHC. Should we include that as a caveat to the binary, .app, and Homebrew instructions? And should we make the Haskell Platform item 1 and "recommended," since it installs Happy, etc. by default? I'm thinking something like: > Secondly, you need an installation of GHC, Happy, and other tools for use as your bootstrap compiler environment. > The easiest and recommended way to install all of the necessary components is to install the [https://www.haskell.org/platform/ Haskell Platform]. (If your OS X version predates 10.8, this build (currently of GHC 7.8.3) is known to support as far back as OS X 10.6.) > However, if you would prefer, you can also install a binary distribution of GHC in three other ways, (be warned: if you're using one of these methods, you'll also need to install cabal and properly configure it, and then install other necessary packages): > 1. Install a binary distribution from GHC. > 2. Get the relocatable .app bundle using ?ghcformacosx > 3. Use one of Fink, MacPorts or Homebrew. Thoughts? I'm not sure what all goes into installing GHC that doesn't come with the Haskell Platform, and I'm not familiar enough with `cabal` to give clear recommendations, so what is written above should probably be elaborated on. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:23:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:23:42 -0000 Subject: [GHC] #8812: Make *_stub.c files available again In-Reply-To: <045.6e7f0d1ca3f060bc68fc22b159c45464@haskell.org> References: <045.6e7f0d1ca3f060bc68fc22b159c45464@haskell.org> Message-ID: <060.42e328c74a86889abbe33e2c3bb46b4b@haskell.org> #8812: Make *_stub.c files available again -------------------------------------+------------------------------------- Reporter: ralphb | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Driver Comment: For reference, the last major change to the handling of *_stub.c files was in: {{{ commit 7b0ff1792d699ff02a604163c9ccf4a98a1ca3eb Author: Simon Marlow Date: Mon Jan 31 10:32:24 2011 +0000 Merge _stub.o files into the main .o file (Fixes #3687 and #706) Now GHC still generates the _stub.c files, but the object file is automatically merged into the main .o file for a module. This means that build systems (including GHC's own) no longer need to worry about looking for _stub.o files and including them when linking. I had to do lots of refactoring in DriverPipeline to make this work; now there's a monad to carry around all the information, and everything is a lot tidier. The _stub.c is now created as a temporary file and removed after compilation (unless the -keep-tmp-files flag is on). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:24:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:24:03 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.afa06a664dd4c5b60dee941fbb8ff2ff@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ihmccreery): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:41:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:41:37 -0000 Subject: [GHC] #9781: Make list monad operations fuse In-Reply-To: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> References: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> Message-ID: <060.e50632b1e5955135573e39f4287a9a17@haskell.org> #9781: Make list monad operations fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D455 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 ekmett]: > I have no issues with improving fusion for do sugared lists, the question is if it is possible to achieve this change with just a libraries fix or if you need to go into the compiler. > > There is a lot of crazy code down in the list comprehension module that gets used to make lists fast there. It isn't clear to me how we'd lean on it. The easy way is to ''use'' the list comprehension desugaring, as in the linked code review. The hard way (because it makes us hide it in some imports) is to move `concatMap` from `GHC.List` into `GHC.Base` and use `xs >>= f = concatMap f xs`, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:42:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:42:13 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.2e38f3d681f58c7be5ecbcc6c98301b9@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ihmccreery): I made the changes recommended above, but they should probably be reviewed again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:48:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:48:55 -0000 Subject: [GHC] #3280: The order of arguments to the function passed to nubBy got swapped somehow In-Reply-To: <044.3c8fa074464e1da7a1a920048af3ac0f@haskell.org> References: <044.3c8fa074464e1da7a1a920048af3ac0f@haskell.org> Message-ID: <059.3eadb9281aa805f79ed0b42fb3a981fc@haskell.org> #3280: The order of arguments to the function passed to nubBy got swapped somehow -------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | -------------------------------------+--------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127" Preserve argument order to (==)/eq in nub and nubBy This makes nub and nubBy behave as specified in the Haskell 98 Report. This reverts 0ad9def53842e86fb292eccb810190711c42d7c5, and fixes #3280, #7913 and #2528 (properly). Before this change, the output of `T2528` was (4x wrong): ``` [A,B] [1,2] False False ``` Reviewed By: dfeuer, ekmett, austin, hvr Differential Revision: https://phabricator.haskell.org/D238 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:48:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:48:55 -0000 Subject: [GHC] #7913: Argument order not preserved by nubBy In-Reply-To: <046.71badb87ed4d077930b6019bd00cb4be@haskell.org> References: <046.71badb87ed4d077930b6019bd00cb4be@haskell.org> Message-ID: <061.a60aca8aa9fe2914bb2cb6498651d562@haskell.org> #7913: Argument order not preserved by nubBy -------------------------------------+------------------------------------- Reporter: paullik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: nubBy Operating System: Linux | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127" Preserve argument order to (==)/eq in nub and nubBy This makes nub and nubBy behave as specified in the Haskell 98 Report. This reverts 0ad9def53842e86fb292eccb810190711c42d7c5, and fixes #3280, #7913 and #2528 (properly). Before this change, the output of `T2528` was (4x wrong): ``` [A,B] [1,2] False False ``` Reviewed By: dfeuer, ekmett, austin, hvr Differential Revision: https://phabricator.haskell.org/D238 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 16:48:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 16:48:55 -0000 Subject: [GHC] #2528: documentation for nub and nubBy should be corrected, extended or removed. In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@haskell.org> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@haskell.org> Message-ID: <062.b304b052bc07c767df6e5ca37cf41e88@haskell.org> #2528: documentation for nub and nubBy should be corrected, extended or removed. -----------------------------------+------------------------------------ Reporter: jdressel | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127" Preserve argument order to (==)/eq in nub and nubBy This makes nub and nubBy behave as specified in the Haskell 98 Report. This reverts 0ad9def53842e86fb292eccb810190711c42d7c5, and fixes #3280, #7913 and #2528 (properly). Before this change, the output of `T2528` was (4x wrong): ``` [A,B] [1,2] False False ``` Reviewed By: dfeuer, ekmett, austin, hvr Differential Revision: https://phabricator.haskell.org/D238 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 17:14:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 17:14:24 -0000 Subject: [GHC] #9295: Deadlock in forkProcess In-Reply-To: <044.090d8a79b478134070085ba877094a40@haskell.org> References: <044.090d8a79b478134070085ba877094a40@haskell.org> Message-ID: <059.5d92e583c42b2d01ef7f6a21a57d3197@haskell.org> #9295: Deadlock in forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D59 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D59 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 17:15:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 17:15:20 -0000 Subject: [GHC] #9295: Deadlock in forkProcess In-Reply-To: <044.090d8a79b478134070085ba877094a40@haskell.org> References: <044.090d8a79b478134070085ba877094a40@haskell.org> Message-ID: <059.d7d9d4430c9b34fe320f2e36e615a0a3@haskell.org> #9295: Deadlock in forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D59 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: 7.8.3 => 7.8.4 Comment: This was merged and will be part of 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 17:15:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 17:15:42 -0000 Subject: [GHC] #9296: Acquire all_tasks_mutex in forkProcess In-Reply-To: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> References: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> Message-ID: <059.6f31cacbf546a030cb9d8a2f6ad3c110@haskell.org> #9296: Acquire all_tasks_mutex in forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D60 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D60 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 17:16:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 17:16:33 -0000 Subject: [GHC] #9296: Acquire all_tasks_mutex in forkProcess In-Reply-To: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> References: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> Message-ID: <059.a42564d257edc01deaca8d29d3fd0969@haskell.org> #9296: Acquire all_tasks_mutex in forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D60 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.3 => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 17:19:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 17:19:42 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.d75f57bf1962641ae4727c0dca497d67@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I'm not keen on recommending haskell platform as the primary. `cabal install alex happy` should suffice. I will adjust your changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 17:20:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 17:20:59 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.bfd922eb4b67fa1781687fa3bdb3d6d7@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): for subsequent changes, lets talk it out a teeny bit before doing any further edits? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 17:48:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 17:48:21 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.de21546f42e285ed1897e925f77d3297@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun004 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 17:59:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 17:59:22 -0000 Subject: [GHC] #7913: Argument order not preserved by nubBy In-Reply-To: <046.71badb87ed4d077930b6019bd00cb4be@haskell.org> References: <046.71badb87ed4d077930b6019bd00cb4be@haskell.org> Message-ID: <061.312939acda28f85152a61dada1654e1f@haskell.org> #7913: Argument order not preserved by nubBy -------------------------------------+------------------------------------- Reporter: paullik | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Prelude | Version: 7.6.3 Resolution: fixed | Keywords: nubBy Operating System: Linux | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 18:00:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 18:00:46 -0000 Subject: [GHC] #2528: documentation for nub and nubBy should be corrected, extended or removed. In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@haskell.org> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@haskell.org> Message-ID: <062.70bc49d72c45c778b2ec41cf8dc68370@haskell.org> #2528: documentation for nub and nubBy should be corrected, extended or removed. -------------------------------------+------------------------------------- Reporter: jdressel | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.8.2 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 18:12:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 18:12:04 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.ac63faa685426c10d653cac00a7cf445@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Profiling Comment: For reference: the change needs to be made in `rts/Profiling.c`. {{{ fprintf(prof_file, "%6s %11s %5s %5s %5s %5s", "no.", "entries", "%time", "%alloc", "%time", "%alloc"); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 18:16:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 18:16:34 -0000 Subject: [GHC] #9295: Deadlock in forkProcess In-Reply-To: <044.090d8a79b478134070085ba877094a40@haskell.org> References: <044.090d8a79b478134070085ba877094a40@haskell.org> Message-ID: <059.e0a77522a15bc49706b2c7ef2296ae57@haskell.org> #9295: Deadlock in forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D59 | -------------------------------------+------------------------------------- Comment (by thomie): In case Phabricator references are not permanent: fixed in commit 39630ab15cc0607103dc4ef3d9089de44ef17c2d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 18:18:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 18:18:58 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.164ade3d89de24c938116f0f012108c9@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ihmccreery): Awesome, thanks, good to know about Haskell Platform. Yup, you got it. I was trying to be helpful and unload as much work as possible, but I know I'm new to this and don't really know what I'm doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 18:19:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 18:19:33 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.b14979002d54b202177c98807c825ecb@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ihmccreery): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 18:21:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 18:21:54 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.a5ff3645feccc9ae0bb376259fa1b507@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): no, this is great, and i certainly make more headway when i have someone to talk to. So happy to guide. That said, sometimes I say things that are opinion rather than fact :) Maybe we should have the rule that "the wiki docs on building GHC are ONLY for current GHC head"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 18:33:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 18:33:54 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.d2b55a596035c0b4d5109f12f52169a9@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ihmccreery): That makes sense to me. I have to admit that it's not really clear who should & shouldn't edit which Wiki pages. It seems a little odd that there would be such a strict rule for that section, with no rules for any other section: [https://ghc.haskell.org/trac/ghc/wiki] > Please help us improve the information on the GHC developer's wiki. You can easily do this by editing the wiki directly. Just register an account, and then edit away. Alternatively, log in as user guest with password guest (but we'd prefer you to create an account, because it enables us to contact you if necessary). The Help/Guide link at the top of every page gives a good description of the markup language and how to use Trac in general. Maybe there is a better way? Maybe just a general rule: > Please help us improve the information on the GHC developer's wiki. If you're not sure what edit to make, go ahead and submit a documentation bug ticket. Otherwise, you can easily edit the wiki directly. Just register an account, and then edit away. Alternatively, log in as user guest with password guest (but we'd prefer you to create an account, because it enables us to contact you if necessary). The Help/Guide link at the top of every page gives a good description of the markup language and how to use Trac in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 19:01:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 19:01:57 -0000 Subject: [GHC] #9618: Undocument ImpredicativeTypes In-Reply-To: <045.05901419138923a568c2731a51d0dcf7@haskell.org> References: <045.05901419138923a568c2731a51d0dcf7@haskell.org> Message-ID: <060.9af6d8b9aef4601e3254632e7c69444f@haskell.org> #9618: Undocument ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #8808 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8808 Comment: Perhaps never showing the following suggestion either, see `compiler/typecheck/TcErrors.lhs`: {{{ Perhaps you want ImpredicativeTypes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 19:39:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 19:39:58 -0000 Subject: [GHC] #9618: Undocument ImpredicativeTypes In-Reply-To: <045.05901419138923a568c2731a51d0dcf7@haskell.org> References: <045.05901419138923a568c2731a51d0dcf7@haskell.org> Message-ID: <060.454c1149d1a86e8d5d1aeef26a17fbf4@haskell.org> #9618: Undocument ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #8808 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm not convinced `ImpredicativeTypes` should be removed from the manual. Sometimes^[''citation needed'']^ I have needed `ImpredicativeTypes` to get my code to type check. `ImpredicativeTypes` isn't ''wrong'' -- it's just very, very rough around the edges. It won't (as far as I know) cause your code to segfault or otherwise go astray. The extension just doesn't work in all the contexts we might like it to. So, instead of removing it altogether, I think we should label it as experimental and very limited. That all said, I don't feel terribly strongly about this and am happy enough if the majority disagrees with me here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 20:32:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 20:32:51 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.856cd5ebe2918d843430206933f3f78a@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D452 | -------------------------------------+------------------------------------- Comment (by goldfire): I think this should be enabled with `-Wall`, even if `haddock` is not enabled. That way, when I'm developing, but before trying to release and build docs, I can learn about bad Haddock comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 20:45:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 20:45:04 -0000 Subject: [GHC] #9009: Confusing error message when loading package with TH In-Reply-To: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> References: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> Message-ID: <063.a083fda3e3444892eb2aa6f87f8ed399@haskell.org> #9009: Confusing error message when loading package with TH -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Package | Version: 7.8.2 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Compiling singletons-1.0 with HEAD failes with: {{{ src/Data/Singletons/Prelude/Ord.hs:48:15: MINIMAL pragmas not (yet) handled by Template Haskell }}} Using ghc 7.8.3 I get a nice error message when compiling Foo.hs: {{{ singletons-1.0$ ghc-7.8.3 -package-db=.cabal-sandbox/x86_64-linux- ghc-7.8.3-packages.conf.d/ Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Failed to load interface for ?Data.Singletons.Single.Monad? There are files missing in the ?singletons-1.0? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. }}} jstolarek: What am I missing? Maybe cabal version (1.20.0.3) is relevant? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 21:18:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 21:18:53 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.8890ae2ad4c583cb30130e75554f1df1@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python ---------------------------------------+---------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by thomie): * cc: thoughtpolice (added) * version: 7.8.2 => 7.8.3 * component: Compiler (Type checker) => Build System * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 21:39:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 21:39:00 -0000 Subject: [GHC] #9017: Confusing error message with PolyKinds In-Reply-To: <044.615421c3033985dd14fef72264fc6cea@haskell.org> References: <044.615421c3033985dd14fef72264fc6cea@haskell.org> Message-ID: <059.63efa576c463a92d6317713bf52a6c22@haskell.org> #9017: Confusing error message with PolyKinds -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: goldfire (added) * component: Compiler => Compiler (Type checker) Comment: > I think it'd better to wait for Richard's upcoming work in which he gives us full-on kind equalities. Now we can use the kind equality to solve the type equality and all will be well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 21:41:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 21:41:27 -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.27b59469dd610f59f883f224afaf20f1@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D458 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D458 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 21:42:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 21:42:28 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.81443eefbd9b0239b73d0fb798df0554@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: => ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 21:45:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 21:45:14 -0000 Subject: [GHC] #8828: Type pattern synonyms (was: allow fully applied type families in instance heads) In-Reply-To: <045.6152be3035980bd31e93fc1579e85689@haskell.org> References: <045.6152be3035980bd31e93fc1579e85689@haskell.org> Message-ID: <060.767cfaed1223f768e950822292598997@haskell.org> #8828: Type pattern synonyms -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: goldfire => * difficulty: Unknown => Project (more than a week) * milestone: => ? Comment: According to the discussion above, this is really a new feature that needs to be designed and implemented. I'm releasing ownership, though I can conceive of a future where I take this on again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:21:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:21:39 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.a02a9e11e3d19ad89c324a5e853ae77c@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun004 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): I haven't been able to recreate this on HEAD (a2e7bbfe7656cf7dbf1af4da5c077ac0b5d41127) on Ubuntu 14.04.1 LTS. Is there a test that fails most of the time? If so, how do you run it to get it to fail frequently? Or are these test failures occurring only rarely? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:21:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:21:45 -0000 Subject: [GHC] #9763: Implement Foldable methods for Array directly In-Reply-To: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> References: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> Message-ID: <060.82650ef66be89d454d51c29a63bd8c3e@haskell.org> #9763: Implement Foldable methods for Array directly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D428 | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * component: Compiler => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:22:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:22:47 -0000 Subject: [GHC] #9540: words is not a good producer; unwords is not a good consumer In-Reply-To: <045.cf07c524c3885055d6c8e1249648041f@haskell.org> References: <045.cf07c524c3885055d6c8e1249648041f@haskell.org> Message-ID: <060.107fad791c46ce16acf12907a7b7e32d@haskell.org> #9540: words is not a good producer; unwords is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D375 | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * differential: D375 => Phab:D375 * component: Compiler => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:23:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:23:11 -0000 Subject: [GHC] #9742: The default definitions of foldl1 and foldr1 are too strict In-Reply-To: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> References: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> Message-ID: <060.99a09a58703fb979d5c7ae7f9b61d2ce@haskell.org> #9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D423 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:23:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:23:28 -0000 Subject: [GHC] #9759: Add Alternative wrapper to Data.Monoid In-Reply-To: <045.9ddae74098f5edc53dc82839cb308d90@haskell.org> References: <045.9ddae74098f5edc53dc82839cb308d90@haskell.org> Message-ID: <060.44d2ffc069e1119568ab7df28942fcd1@haskell.org> #9759: Add Alternative wrapper to Data.Monoid -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D422 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:23:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:23:47 -0000 Subject: [GHC] #9761: Foldable cannot be derived by GND due to redundant contexts In-Reply-To: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> References: <045.3c6bfe9e435595367d2d85bbbb38a9fa@haskell.org> Message-ID: <060.1c300ccf0249d8417009d98034e1ace7@haskell.org> #9761: Foldable cannot be derived by GND due to redundant contexts -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D425 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:30:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:30:45 -0000 Subject: [GHC] #9714: Un-`wire` Integer type In-Reply-To: <042.d9e6c84c3f736b36a268197d3ac72a0d@haskell.org> References: <042.d9e6c84c3f736b36a268197d3ac72a0d@haskell.org> Message-ID: <057.ead543981ef42404589a277dd61dd250@haskell.org> #9714: Un-`wire` Integer type -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Integer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: #9281 Blocking: | Differential Revisions: Phab:D351 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:31:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:31:14 -0000 Subject: [GHC] #9767: Add isSubsequenceOf to Data.List In-Reply-To: <047.a10d1fc86511a46e367bb032e95edccd@haskell.org> References: <047.a10d1fc86511a46e367bb032e95edccd@haskell.org> Message-ID: <062.dbd72fb44e6aa34573b4697de66cca75@haskell.org> #9767: Add isSubsequenceOf to Data.List -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:54:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:54:12 -0000 Subject: [GHC] #8822: Allow -- ^ Haddock syntax on record constructors In-Reply-To: <047.9e31292a58062fe675a519afe89cb025@haskell.org> References: <047.9e31292a58062fe675a519afe89cb025@haskell.org> Message-ID: <062.2aa662be335a4b8aaae26c204bd63730@haskell.org> #8822: Allow -- ^ Haddock syntax on record constructors -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9770 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9770 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 7 23:55:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Nov 2014 23:55:50 -0000 Subject: [GHC] #9770: GHC Parser fails on Haddock comment on parameter of a function record field In-Reply-To: <044.6605f3c60f34bfc83935db1034506191@haskell.org> References: <044.6605f3c60f34bfc83935db1034506191@haskell.org> Message-ID: <059.2713e21ef521afa63ccbbcaae35d9147@haskell.org> #9770: GHC Parser fails on Haddock comment on parameter of a function record field -------------------------------------+------------------------------------- Reporter: boris | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: Haddock Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8822 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #8822 Comment: Thank you for the report. Let's combine all these parser issues related to haddock comments at #8822. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 00:16:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 00:16:15 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.115de98c790f05a591b5445ff5b231bd@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler (Parser) => Test Suite * milestone: => 7.10.1 Comment: Thank you for the report. I confirm this problem does not occur in 7.6.3, and does occur with 7.8.1 and HEAD. I can not find anything about this in the 7.8.1 changelog. I did find a related change, but then for the GHC Api pretty printer. {{{ commit 6f32f9b429814499cfde1367e59d3e46bffc4925 Author: simonpj at microsoft.com Date: Thu Jul 23 15:24:11 2009 +0000 Print explicit braces and semicolons in do-notation By printing explicit braces we make it more likely that pretty-printed code will be acceptable if fed back into GHC. See http://www.haskell.org/pipermail/glasgow-haskell- users/2009-July/017554.html }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 00:16:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 00:16:46 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.adfdbac3483f68558188d7f757d4037d@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 7.8.2 => 7.8.1 * component: Test Suite => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 00:29:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 00:29:33 -0000 Subject: [GHC] #9032: Panic with self-import In-Reply-To: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> References: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> Message-ID: <063.66291cfeea2d94933cc27ac4f1a3e295@haskell.org> #9032: Panic with self-import -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #1012 time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Template Haskell * milestone: => 7.10.1 Old description: > I've run into GHC panic with this code: > > {{{ > {-# OPTIONS_GHC -fno-warn-unused-imports #-} > > module Singletons.Star where > > import Data.Singletons.Prelude > import Data.Singletons.Decide > import Data.Singletons.CustomStar > import Singletons.Nat > import Singletons.Star -- <------- HERE > > data Vec :: * -> Nat -> * where > VNil :: Vec a Zero > VCons :: a -> Vec a n -> Vec a (Succ n) > > $(singletonStar [''Nat, ''Int, ''String, ''Maybe, ''Vec]) > }}} > > This is a test in `singletons` package that leads to a panic when run: > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-unknown-linux): > tcIfaceGlobal (local): not found: > singletons-1.0:Singletons.Star.TFCo:R:DemoteRep*KProxy{tc r0} > [] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > I was unable to minimize the test case. Reproducing requires following > steps: > > 1. Installing latest th-desugar library from github: > > {{{ > git clone https://github.com/goldfirere/th-desugar.git > cd th-desugar > cabal install > }}} > > 2. Getting latest development version of singletons: > > {{{ > git clone https://github.com/goldfirere/singletons > cd singletons > git checkout 56734c2bda721cb9a6a3021b901e3b29d6564f0c > make tests > }}} > > All should go well. Now you need to edit file `tests/compile-and- > dump/Singletons/Star.hs` and uncomment `import Singletons.Star` line. It > should be possible to reproduce the bug with: > > {{{ > cd tests/compile-and-dump/ghc -package-name singletons-1.0 > Singletons/Star.hs -i../../dist/build -c -XTemplateHaskell > }}} > > It's important to run `make tests` first so that all interface files > required by `Star.hs` are in place. New description: A test in the `singletons` package leads to a panic when run: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: singletons-1.0:Singletons.Star.TFCo:R:DemoteRep*KProxy{tc r0} [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Edit: see comment:1 for a testcase. -- Comment: Still present in 7.9. I have cleaned up the description a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 00:54:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 00:54:48 -0000 Subject: [GHC] #9769: User's Guide missing from Windows binary distributions (was: ghc-7.8.3-x86_64-unknown-mingw32.tar.xz missing User's Guide) In-Reply-To: <051.92b9ec823fa5402a4972db991a6f829e@haskell.org> References: <051.92b9ec823fa5402a4972db991a6f829e@haskell.org> Message-ID: <066.75de8d6215ba4c15e2c6248e0000f8cc@haskell.org> #9769: User's Guide missing from Windows binary distributions -------------------------------------+------------------------------------- Reporter: | Owner: Dangthrimble | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Documentation => Build System * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Sorry to hear you ran into this. You can access the latest user manual online here for the moment: https://www.haskell.org/ghc/docs/latest/html/users_guide/index.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 00:55:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 00:55:20 -0000 Subject: [GHC] #9769: User's Guide missing from Windows binary distributions In-Reply-To: <051.92b9ec823fa5402a4972db991a6f829e@haskell.org> References: <051.92b9ec823fa5402a4972db991a6f829e@haskell.org> Message-ID: <066.be025792b200ea7f9d1170a2483626b0@haskell.org> #9769: User's Guide missing from Windows binary distributions -------------------------------------+------------------------------------- Reporter: | Owner: Dangthrimble | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 01:04:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 01:04:20 -0000 Subject: [GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot In-Reply-To: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> References: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> Message-ID: <057.eefe3c5773e136a8162c7da60cc75478@haskell.org> #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Build System => Driver * milestone: 7.8.4 => 7.10.1 Comment: Could you attach Myfile.hs and Other.hs? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 01:11:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 01:11:47 -0000 Subject: [GHC] #9755: Unhelpful error message when -XScopedTypeVariables is omitted In-Reply-To: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> References: <048.c66518d3dedb875be8c35f66a2b9ad76@haskell.org> Message-ID: <063.fc69124e36ad2d20e35d0b13ecd85d82@haskell.org> #9755: Unhelpful error message when -XScopedTypeVariables is omitted -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (removed) * component: GHCi => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 02:04:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 02:04:48 -0000 Subject: [GHC] #8699: Multiple test faliures on 32-bit Linux systems. In-Reply-To: <047.0a18fb8eba467de4cead3e8638814c85@haskell.org> References: <047.0a18fb8eba467de4cead3e8638814c85@haskell.org> Message-ID: <062.f0c6efa4025bb2548394ba46f076ec3e@haskell.org> #8699: Multiple test faliures on 32-bit Linux systems. -------------------------------------------+----------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+----------------------------- Changes (by Fuuzetsu): * status: new => closed * resolution: => wontfix Comment: I don't think anyone is going to try and chase these old bugs and I don't have any new data to update with so closing as wontfix, please open separate issues if still needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 04:10:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 04:10:07 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations Message-ID: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: pattern synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Moderate (less | result at runtime than a day) | Test Case: Blocked By: | Blocking: Related Tickets: 9732 | Differential Revisions: -------------------------------------+------------------------------------- As discovered while investigating #9732, if you have something like {{{ {-# LANGUAGE PatternSynonyms, MagicHash #-} import GHC.Base pattern P = True f :: Bool -> Int# f P = 42# }}} `f` is compiled into {{{ Main.f :: GHC.Types.Bool -> GHC.Prim.Int# [LclIdX, Str=DmdType] Main.f = letrec { f_apU :: GHC.Types.Bool -> GHC.Prim.Int# [LclId, Str=DmdType] f_apU = \ (ds_dq1 :: GHC.Types.Bool) -> break<2>() let { fail_dq2 :: GHC.Prim.Void# -> GHC.Prim.Int# [LclId, Str=DmdType] fail_dq2 = \ (ds_dq3 [OS=OneShot] :: GHC.Prim.Void#) -> Control.Exception.Base.patError @ GHC.Prim.Int# "unboxed.hs:7:1-9|function f"# } in case fail_dq2 GHC.Prim.void# of wild_00 { __DEFAULT -> (case break<1>() 42 of wild_00 { __DEFAULT -> Main.$mP @ GHC.Prim.Int# ds_dq1 wild_00 }) wild_00 }; } in f_apU }}} Note how `fail_dq2` is applied on `void#` _before_ the pattern match, meaning the following expression: {{{ I# (f True) }}} will fail with {{{ *** Exception: unboxed.hs:7:1-9: Non-exhaustive patterns in function f }}} This is because the the type of `P`'s matcher, instantiated for its use in `f`, is {{{ $mP :: Bool -> Int# -> Int# -> Int# }}} so of course it is strict both on the success and the failure continuation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 04:59:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 04:59:27 -0000 Subject: [GHC] #9763: Implement Foldable methods for Array directly In-Reply-To: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> References: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> Message-ID: <060.3a90f9dcba8fed33c723bb1d2306634d@haskell.org> #9763: Implement Foldable methods for Array directly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D459 | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: Phab:D428 => Phab:D459 Comment: The patch now includes tests, as requested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 08:21:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 08:21:39 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations In-Reply-To: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> References: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> Message-ID: <060.1e9ddc0d83d2e5857d46d95806f4116b@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 9732 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"474e535b6b121809a8d75df5a4c37dc574d3d302/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="474e535b6b121809a8d75df5a4c37dc574d3d302" In pattern synonym matchers, support unboxed continuation results (fixes #9783). This requires ensuring the continuations have arguments by adding a dummy Void# argument when needed. This is so that matching on a pattern synonym is lazy even when the result is unboxed, e.g. pattern P = () f P = 0# In this case, without dummy arguments, the generated matcher's type would be $mP :: forall (r :: ?). () -> r -> r -> r which is called in `f` at type `() -> Int# -> Int# -> Int#`, so it would be strict, in particular, in the failure continuation of `patError`. We work around this by making sure both continuations have arguments: $mP :: forall (r :: ?). () -> (Void# -> r) -> (Void# -> r) -> r Of course, if `P` (and thus, the success continuation) has any arguments, we are only adding the extra dummy argument to the failure continuation. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 08:22:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 08:22:13 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations In-Reply-To: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> References: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> Message-ID: <060.eb32c4a799535d74bf9426da335dccf0@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 9732 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 11:10:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 11:10:01 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations In-Reply-To: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> References: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> Message-ID: <060.a6bfd073f5793ab1466e4b5ae91b788c@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 9732 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): cactus: if you meant for thoughtpolice to merge this into 7.8.4, you should set the milestone to 7.8.4. If it can wait till 7.10.1, the status of the ticket can be changed to close (it's already merged). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 13:36:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 13:36:25 -0000 Subject: [GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations In-Reply-To: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> References: <045.fbfedd3216f2b9704ce7d408adca131b@haskell.org> Message-ID: <060.1caf00cb30e4f0fa266f1ddfd8006e49@haskell.org> #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 9732 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * milestone: 7.10.1 => 7.8.4 Comment: @thomie: Thanks, yes I think this one should be merged into 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 16:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 16:50:24 -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.5370a7996bd2db340d675d27a60527b7@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): It seems there are a couple of options: 1. Solve this problem by making DataKinds always promote to `'S`, and never to `S`. I'm sure this was long-debated when DataKinds was introduced, and is therefore unlikely to happen. 2. Add a very mild message anytime there is a type error about a type that shares a name with a promoted constructor, something like "Be aware that S could refer to the constructor promoted from blah" Either one is an improvement over the current black-holing of promoted types when a non-promoted type is in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 18:30:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 18:30:11 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.7a52aac79ec001d0f97f33f4e20e573d@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) Comment: Replying to [comment:5 ekmett]: > Ack! Now I see what you mean. > > `Applicative` not even being in the package _is_ a problem. As a reminder this is still an issue, here's a suggestion together with a counter-argument: As a pragmatic solution, one could simply make available the `Applicative` typeclass in `haskell2010`. That way you can define `Monad` instance, iff you also define `Functor` **and** `Applicative` instances. However, now you end up with a "Haskell2010" program that works with GHC 7.10 but not GHC 7.{0,2,4,8} (or any other strict-Haskell2010 mode compiler), as the program refers to a non-standard `Applicative` only available in GHC 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 18:37:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 18:37:55 -0000 Subject: [GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended In-Reply-To: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> References: <049.e149f91c137e3ce22a8cd765a774d980@haskell.org> Message-ID: <064.26b78d261175ace86a8ac94f27e52c26@haskell.org> #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) Documentation bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): strict rule for which? by rule I meant: that the OS X section section should show only most current GHC HEAD and RELEASE build directions, and those wanting older versions should just look at the pages history. If only to make sure that the people who are reading it (likely first time GHC contributors almost exclusively) have clear simple directions. So more like an information policy to make it less confusing for folks to get started? not sure. That change in language is a good one, though maybe it should say something about "open a ticket or email ghc-devs if you're unsure and would like feedback before making the change". That said, theres definitely value in keeping the conversation history on Trac in a tracked (hah) way. If you know what youre doing, the WIKI, unlike ghc's git repo, doesnt have a code review process! Or at least, theres not so many people making general audience wiki edits, so that sort of review process isn't needed? IDK, i wonder how larger projects navigate this stuff. Either way, this is valuable stuff to do/ask about! Thank you! (and keep at it!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 19:18:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 19:18:48 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.cc5ca18d2e4e2623e8a6bae31d5bc231@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): There is no silver bullet here. The more I think on it, the more it strikes me that the best option is for us to just give up on these packages as a failed experiment. Neither hackage has ever really received any traction or picked up a coherent usage story. Every attempt folks (including me) have made to put forth them as something someone might use in practice has been rather rightly derided as unrealistic. We'd also get to clear `old-locale` and `old-time` out of the core. Any solution that involves bringing `Applicative` in could just as well be done outside of the GHC development process, so if a user base wanted to rally behind a `haskell98` / `haskell2010` package, it could be built out in `cabal` by anyone; we could put out a call for an active maintainer who wants to own it. It is only if we wanted to isolate `haskell2010` users further from the community by making them use their own `Monad`, etc. that we might have to keep `haskell2010` and `haskell98` as core packages -- but then only for compiler support for do sugar, and even that could probably be done with enough work. It doesn't strike me as a thing we're remotely ready to do though. It isn't clear it'd work sufficiently well for any appreciable number of users to at all justify the time and maintenance. Which brings us back to the option of just cutting these packages loose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 19:24:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 19:24:11 -0000 Subject: [GHC] #9784: Allow Qualified Promoted Types Message-ID: <047.546c05d155a967089478b2cd78e20337@haskell.org> #9784: Allow Qualified Promoted Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The program {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where import Data.Proxy data MyNat = Z | S MyNat bar :: Proxy Foo.'Z -> Int bar _ = 0 }}} fails with the error {{{ Foo.hs:7:17: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall . Failed, modules loaded: none. }}} I believe the program above should compile without error. In the example above, I could make the code compile with my intended meanign using `Z`, `'Z`, or even `Foo.Z` in place of `Foo.'Z`, all of which refer to `Foo.'Z`. However, if there is also a vanilla type `Z` in scope and another promoted constructor `'Z` in scope, I have no way to disambiguate the reference to `'Z` in `bar`: - `Z` and `Foo.Z` refer to the vanilla type - `'Z` could be from the promoted `MyNat` constructor, or from the other module Concretely, I could import `Data.Type.Natural` from [https://hackage.haskell.org/package/type-natural type-natural], which also defines the promoted constructor `'Z`. {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where import Data.Proxy import Data.Type.Natural data MyNat = Z | S MyNat bar :: Proxy Foo.'Z -> Int bar _ = 0 }}} In this case, there is no way for me to indicate that `bar` has the type `Foo.'Z -> Int` As a side note, if I do as the error suggests and use`RankNTypes`, I get the same error message. It's a bit strange for GHC suggest adding an extension that is already enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 19:26:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 19:26:06 -0000 Subject: [GHC] #9784: Allow Qualified Promoted Types In-Reply-To: <047.546c05d155a967089478b2cd78e20337@haskell.org> References: <047.546c05d155a967089478b2cd78e20337@haskell.org> Message-ID: <062.69c12b2bb7574e4b6a548b28b5c73d41@haskell.org> #9784: Allow Qualified Promoted Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > The program > > {{{#!hs > {-# LANGUAGE DataKinds #-} > module Foo where > import Data.Proxy > > data MyNat = Z | S MyNat > > bar :: Proxy Foo.'Z -> Int > bar _ = 0 > }}} > fails with the error > {{{ > Foo.hs:7:17: > Illegal symbol '.' in type > Perhaps you intended to use RankNTypes or a similar language > extension to enable explicit-forall syntax: forall . > Failed, modules loaded: none. > }}} > > I believe the program above should compile without error. In the example > above, I could make the code compile with my intended meanign using `Z`, > `'Z`, or even `Foo.Z` in place of `Foo.'Z`, all of which refer to > `Foo.'Z`. However, if there is also a vanilla type `Z` in scope and > another promoted constructor `'Z` in scope, I have no way to disambiguate > the reference to `'Z` in `bar`: > - `Z` and `Foo.Z` refer to the vanilla type > - `'Z` could be from the promoted `MyNat` constructor, or from the > other module > > Concretely, I could import `Data.Type.Natural` from > [https://hackage.haskell.org/package/type-natural type-natural], which > also defines the promoted constructor `'Z`. > > {{{#!hs > {-# LANGUAGE DataKinds #-} > module Foo where > import Data.Proxy > import Data.Type.Natural > > data MyNat = Z | S MyNat > > bar :: Proxy Foo.'Z -> Int > bar _ = 0 > }}} > > In this case, there is no way for me to indicate that `bar` has the type > `Foo.'Z -> Int` > > As a side note, if I do as the error suggests and use`RankNTypes`, I get > the same error message. It's a bit strange for GHC suggest adding an > extension that is already enabled. New description: The program {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where import Data.Proxy data MyNat = Z | S MyNat bar :: Proxy Foo.'Z -> Int bar _ = 0 }}} fails with the error {{{ Foo.hs:7:17: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall . Failed, modules loaded: none. }}} I believe the program above should compile without error. In the example above, I could make the code compile with my intended meanign using `Z`, `'Z`, or even `Foo.Z` in place of `Foo.'Z`, all of which refer to `Foo.'Z`. However, if there is also a vanilla type `Z` in scope and another promoted constructor `'Z` in scope, I have no way to disambiguate the reference to `'Z` in `bar`: - `Z` and `Foo.Z` refer to the vanilla type - `'Z` could be from the promoted `MyNat` constructor, or from the other module Concretely, I could import `Data.Type.Natural` from [https://hackage.haskell.org/package/type-natural type-natural], which also defines the promoted constructor `'Z`. {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where import Data.Proxy import Data.Type.Natural data MyNat = Z | S MyNat bar :: Proxy Foo.'Z -> Int bar _ = 0 }}} In this case, there is no way for me to indicate that `bar` has the type `Foo.'Z -> Int`. Although a user cannot define the a type beginning with a tick, they are perfectly valid types to refer to. I suspect the parser is failing to make this distinction, at least in the context of name qualification. As a side note, if I do as the error suggests and use`RankNTypes`, I get the same error message. It's a bit strange for GHC suggest adding an extension that is already enabled. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 19:31:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 19:31:52 -0000 Subject: [GHC] #9784: Allow Qualified Promoted Types In-Reply-To: <047.546c05d155a967089478b2cd78e20337@haskell.org> References: <047.546c05d155a967089478b2cd78e20337@haskell.org> Message-ID: <062.92f3f579b8ae4414f4eeba7b0a761afb@haskell.org> #9784: Allow Qualified Promoted Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): It's `'Foo.Z` not `Foo.'Z`. `Foo.Z` is the name here; there is no "type beginning with a tick", that is just syntax to disambiguate namespaces. (Think like `(Map.!)`, etc.) Good point about the `RankNTypes` error message though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 19:43:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 19:43:13 -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.6bd99a3a62b1d883e8319ca0cff08ede@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well, DataKinds does always promote to `'S`. It just also promotes to `S`. But you could avoid ever using the un-`'`ed form of a promoted constructor; that's up to you. Are you asking for a `-fwarn-implicit- promoted-constructors`? That should probably not be the default, as the currently common style is not to write `'True` and `'False` everywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 21:42:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 21:42:28 -0000 Subject: [GHC] #9781: Make list monad operations fuse In-Reply-To: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> References: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> Message-ID: <060.fa1b2779ff079140caedbd7ab81de4f6@haskell.org> #9781: Make list monad operations fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D455 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 21:50:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 21:50:43 -0000 Subject: [GHC] #9785: Link error when using Data.Vector in separate compilation mode Message-ID: <043.0a1e558a600a234b53947fbc68358d23@haskell.org> #9785: Link error when using Data.Vector in separate compilation mode -------------------------------------+------------------------------------- Reporter: yugr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I compile attached files all at once they link fine: $ ghc A.hs B.hs Main.hs Linking Main.exe ... But with separate compilation they produce link errors: $ rm -f *.o *.hi $ ghc -c A.hs $ ghc -c B.hs $ ghc -c Main.hs $ ghc A.o B.o Main.o B.o:fake:(.text+0x34): undefined reference to `vectorzm0zi10zi11zi0_DataziVector_fromList_closure' B.o:fake:(.data+0x20): undefined reference to `vectorzm0zi10zi11zi0_DataziVector_fromList_closure' c:/program files/haskell platform/2014.2.0.0/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: B.o: bad reloc address 0x20 in section `.data' c:/program files/haskell platform/2014.2.0.0/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Invalid operation collect2: ld returned 1 exit status I'm using the latest Haskell Platform 2014.2.0.0 for Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 22:27:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 22:27:39 -0000 Subject: [GHC] #9785: Link error when using Data.Vector in separate compilation mode In-Reply-To: <043.0a1e558a600a234b53947fbc68358d23@haskell.org> References: <043.0a1e558a600a234b53947fbc68358d23@haskell.org> Message-ID: <058.afeb14706bde18db725d5f0967ead491@haskell.org> #9785: Link error when using Data.Vector in separate compilation mode -------------------------------------+------------------------------------- Reporter: yugr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): This is normal behavior: in the second case you are invoking ghc in one- shot mode, so you need to add `-package vector` explicitly to tell ghc to link against the `vector` package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 22:38:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 22:38:02 -0000 Subject: [GHC] #9784: Allow Qualified Promoted Types In-Reply-To: <047.546c05d155a967089478b2cd78e20337@haskell.org> References: <047.546c05d155a967089478b2cd78e20337@haskell.org> Message-ID: <062.108e9c4a75d44fe2d0c519e3293943b9@haskell.org> #9784: Allow Qualified Promoted Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): Interesting. Instead of suggesting `RankNTypes`, perhaps the error should explain this syntax. If there's a promoted variable in scope (or maybe even if there isn't a promoted variable in scope) `parse error on Foo.'Z (perhaps you meant 'Foo.Z)` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 8 23:26:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Nov 2014 23:26:10 -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.46ec90fdd754232f6ecdf47a061e6a1e@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): @rwbarton `-fwarn-implicit-promoted-constructors` is an interesting suggestion. Just to be clear, I'm imagining that such an option would result in a warning whenever `S` is written but it refers to the same type as a `'S` promoted constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 02:58:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 02:58:01 -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.ce242d2fa7638ba7bb80d0c212362fc3@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I could rally behind calling `-fwarn-unticked-promoted-constructors` the solution to this problem. I'm -0.5 on including text in any error message about `S` the possibility that the user means `'S` -- just seems like noise to me. Note that I've changed the name of the warning flag, as `implicit` conjures up the wrong associations for me. It's interesting to note that I frequently use ticks everywhere in presentations about !DataKinds stuff. (I leave off the ticks in my own code, though.) I think requiring the ticks makes for a better reader experience for folks who are not deep into this. I also think that the ticks should be allowed (but not required) in kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 03:18:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 03:18:54 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.16ef257d5db353d2f19420ad8ebd7fe4@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: GregWeber Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8624 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by GregWeber): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 03:19:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 03:19:01 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.8a4ca40114e8827255e77a3c747226ac@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: GregWeber Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8624 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by GregWeber): https://phabricator.haskell.org/D460 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 03:33:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 03:33:55 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.2ab2d9a506d820501251dd995b989ff4@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: GregWeber Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8624 Test Case: | Blocking: | Differential Revisions: Phab:D460 | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D460 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 04:09:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 04:09:52 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.8fad1838f5d81c6ecdcb0cf0048bbadc@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by GregWeber): I finally made a patch for #9126 that doesn't have failing test cases. I have a better understanding of how the printing works now. For solving this ticket (creating a file of valid Haskell code of the generated Template Haskell), I did have a question about the suggested approach of using the Typechecker output. ddump-splices seems to contain exactly what I want, plus some extra stuff. Is the idea behind using the Typechecker output instead of refactoring the splices that I will get more generated stuff besides just Template Haskell? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 07:12:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 07:12:26 -0000 Subject: [GHC] #7862: Could not deduce (A) from the context (A, ...) In-Reply-To: <045.77e996083183797ec6c495029488c3f8@haskell.org> References: <045.77e996083183797ec6c495029488c3f8@haskell.org> Message-ID: <060.80f619ea4030af7945775f4a6887c0b6@haskell.org> #7862: Could not deduce (A) from the context (A, ...) -------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Another example of this bug: {{{ {-# LANGUAGE AllowAmbiguousTypes, DefaultSignatures, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, UndecidableInstances, PolyKinds, ConstraintKinds, InstanceSigs, TypeFamilies #-} module Control.SmallCategory where import GHC.Exts import Control.Category class Vacuous (a:: i) instance Vacuous a class SmallCategory cat where type Objects cat :: i -> Constraint type Objects cat = Vacuous type Morphisms cat :: a -> a -> b id :: (Objects cat a) => (Morphisms cat) a a (.) :: (Objects cat a, Objects cat b, Objects cat c) => (Morphisms cat) b c -> (Morphisms cat) a b -> (Morphisms cat) a c instance (Category c, Category (Morphisms c)) => SmallCategory c where type Objects c = Vacuous type (Morphisms c) = c id = Control.Category.id (.) = (Control.Category..) src/Control/SmallCategory.hs:34:10: Could not deduce (Category (Morphisms c)) arising from a use of ?Control.Category.id? from the context (Category c, Category (Morphisms c)) bound by the instance declaration at src/Control/SmallCategory.hs:31:10-64 or from (Objects c a) bound by the type signature for id :: (Objects c a) => Morphisms c a a at src/Control/SmallCategory.hs:34:5-6 In the expression: Control.Category.id In an equation for ?id?: id = Control.Category.id In the instance declaration for ?SmallCategory c? src/Control/SmallCategory.hs:35:11: Could not deduce (Category (Morphisms c)) arising from a use of ?Control.Category..? from the context (Category c, Category (Morphisms c)) bound by the instance declaration at src/Control/SmallCategory.hs:31:10-64 or from (Objects c a, Objects c b, Objects c c1) bound by the type signature for (.) :: (Objects c a, Objects c b, Objects c c1) => Morphisms c b c1 -> Morphisms c a b -> Morphisms c a c1 at src/Control/SmallCategory.hs:35:5-7 In the expression: (Control.Category..) In an equation for ?.?: (.) = (Control.Category..) In the instance declaration for ?SmallCategory c? }}} in 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 07:12:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 07:12:56 -0000 Subject: [GHC] #7862: Could not deduce (A) from the context (A, ...) In-Reply-To: <045.77e996083183797ec6c495029488c3f8@haskell.org> References: <045.77e996083183797ec6c495029488c3f8@haskell.org> Message-ID: <060.a69eb2df1b0cd3a19a57b303c89fd4d8@haskell.org> #7862: Could not deduce (A) from the context (A, ...) -------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by spacekitteh): * version: 7.6.2 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 07:26:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 07:26:57 -0000 Subject: [GHC] #9785: Link error when using Data.Vector in separate compilation mode In-Reply-To: <043.0a1e558a600a234b53947fbc68358d23@haskell.org> References: <043.0a1e558a600a234b53947fbc68358d23@haskell.org> Message-ID: <058.fdeb2281957060de2f1d6167a263a040@haskell.org> #9785: Link error when using Data.Vector in separate compilation mode -------------------------------------+------------------------------------- Reporter: yugr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by yugr): * status: new => closed * resolution: => invalid Comment: Thanks and sorry for invalid bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 09:02:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 09:02:59 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.cb35b10b459cf721616416bca22db2ba@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun004 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): For me they never occur when running the test on its own. They only occur during `sh validate --fast`. The difference, perhaps, is that many tests are running at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 13:09:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 13:09:34 -0000 Subject: [GHC] #9034: GHCi panics when given C++ object file on GNU/Linux In-Reply-To: <043.041301d73710117066e0bc737fc4c18c@haskell.org> References: <043.041301d73710117066e0bc737fc4c18c@haskell.org> Message-ID: <058.2c2c0c1e9da348eafb141cc950eca57f@haskell.org> #9034: GHCi panics when given C++ object file on GNU/Linux -------------------------------------+------------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic Operating System: Linux | linking Type of failure: GHCi crash | Architecture: x86_64 (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thomie): Running `ghci -v -lstdc++ doesnotexist.o` shows: {{{ ... Loading object (static) doesnotexist.o ... not found Loading object (dynamic) /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.so ... done ... }}} Shouldn't it try to load `libstdc++.so` before `doesnotexist.o`? And why does it say `(static)`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 13:16:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 13:16:55 -0000 Subject: [GHC] #9040: HPC doesnt work as expected on mac In-Reply-To: <045.879578abba86d88f677377cd5560066c@haskell.org> References: <045.879578abba86d88f677377cd5560066c@haskell.org> Message-ID: <060.efceabde3001622a74917873277446a9@haskell.org> #9040: HPC doesnt work as expected on mac -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code | Version: 7.8.2 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Code Coverage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 14:17:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 14:17:03 -0000 Subject: [GHC] #9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory] In-Reply-To: <048.1430731adc1d95572db5390549fbba3c@haskell.org> References: <048.1430731adc1d95572db5390549fbba3c@haskell.org> Message-ID: <063.38a1501cf57962602e3c1128c2a681d8@haskell.org> #9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory] -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: smartos illumos Resolution: fixed | lndir sdist Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Easy (less than 1 GHC failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Thanks for the bug report. I listed lndir in [wiki:Building/Preparation/Tools], and also in [wiki:Building/Preparation/Linux]. The in-tree lndir is needed on MacOS, according to [wiki:Building/Using]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 14:41:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 14:41:26 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.59692c8d17f9fa3185f099865d25873d@haskell.org> #9513: Building GHC on Windows ----------------------------------------------+--------------------------- Reporter: srutownik | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme * os: Unknown/Multiple => Windows Comment: For others that are running into this problem, please see the greatly improved wiki page [wiki:Building/Preparation/Windows]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 15:15:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 15:15:36 -0000 Subject: [GHC] #7862: Could not deduce (A) from the context (A, ...) In-Reply-To: <045.77e996083183797ec6c495029488c3f8@haskell.org> References: <045.77e996083183797ec6c495029488c3f8@haskell.org> Message-ID: <060.06801b2bb0b6759f71dbb506b5b33b51@haskell.org> #7862: Could not deduce (A) from the context (A, ...) -------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): The problem in comment:5 is unrelated to the original bug report -- it is a !PolyKinds issue. If you turn on `-fprint-explicit-kinds`, you get {{{ Could not deduce (Category k2 (Morphisms (k -> k -> *) k2 * c)) arising from a use of ?Control.Category.id? from the context (Category k c, Category k1 (Morphisms (k -> k -> *) k1 * c)) bound by the instance declaration at Scratch.hs:30:10-64 or from (Objects (k -> k -> *) k2 c a) bound by the type signature for id :: (Objects (k -> k -> *) k2 c a) => Morphisms (k -> k -> *) k2 * c a a at Scratch.hs:33:5-6 In the expression: Control.Category.id In an equation for ?id?: id = Control.Category.id In the instance declaration for ?SmallCategory (k -> k -> *) c? }}} and you can see a more sensible error message. What would be nice here is a note suggesting to turn on `-fprint-explicit- kinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 15:52:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 15:52:45 -0000 Subject: [GHC] #9056: --make paths are not deduplicated In-Reply-To: <054.6d9311fc6ac4a797c0df6e46e05c1bcb@haskell.org> References: <054.6d9311fc6ac4a797c0df6e46e05c1bcb@haskell.org> Message-ID: <069.346903e811ebd577e7cb9de0f937de05@haskell.org> #9056: --make paths are not deduplicated -------------------------------------+------------------------------------- Reporter: | Owner: evincarofautumn | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: Unknown => Easy (less than 1 hour) * component: Compiler => Driver -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 17:53:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 17:53:58 -0000 Subject: [GHC] #9073: small SPECIALIZE INLINE program taking gigabytes of memory to compile In-Reply-To: <044.c7df3af78adcc74c7d6499ca7d538f54@haskell.org> References: <044.c7df3af78adcc74c7d6499ca7d538f54@haskell.org> Message-ID: <059.2adbfc3f8bd1e40b0a6f41cc99710412@haskell.org> #9073: small SPECIALIZE INLINE program taking gigabytes of memory to compile -------------------------------------+------------------------------------- Reporter: dagit | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: worksforme | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Thanks for the report. I can replicate the problem with 7.8.3. It seems to be fixed in HEAD, so please wait for 7.10 to come out, or try with 7.8.4 in a few weeks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 18:05:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 18:05:16 -0000 Subject: [GHC] #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. In-Reply-To: <048.bf4e6160222a10b78f2f4ca8e5795447@haskell.org> References: <048.bf4e6160222a10b78f2f4ca8e5795447@haskell.org> Message-ID: <063.e5d8f79bfb91ee82c950fdb3c0ffe920@haskell.org> #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. -------------------------------------+------------------------------------- Reporter: Westycoot | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: worksforme | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: GHC 7.6.3 indeed panics on the given example, but 7.8.3 does not. {{{ $ ghc-7.8.3 T9077.hs [1 of 1] Compiling Main ( T9077.hs, T9077.o ) T9077.hs:1:12: Record syntax is illegal here: {} }}} Westycoot: please reopen if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 18:33:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 18:33:28 -0000 Subject: [GHC] #9087: Executables in the Linux binaries are not stripped (was: Executables in the 7.8.2 Linux i386 binary tarball are not stripped) In-Reply-To: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> References: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> Message-ID: <060.4731759784992e101634497b18067fab@haskell.org> #9087: Executables in the Linux binaries are not stripped -----------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+------------------------------------ Changes (by thomie): * architecture: x86 => Unknown/Multiple Old description: > At least on i386 Linux, the executables inside the GHC binary tarball > seem to come with debug information. Stripping it noticeably reduces the > binary sizes: > > {{{ > $ file /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc > /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc: ELF 32-bit LSB executable, > Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for > GNU/Linux 2.6.26, > BuildID[sha1]=0x6012a4c86cd3f410ca0e59ab4ac872ce740d03c6, not stripped > > $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc > 1,4M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc > > $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc > > $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc > 1021K /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc > > $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock > 3,2M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock > > $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock > > $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock > 2,3M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock > }}} > > Do we really need to include the debug info for exes? New description: The executables inside the GHC binary tarball seem to come with debug information. Stripping it noticeably reduces the binary sizes: {{{ $ file /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x6012a4c86cd3f410ca0e59ab4ac872ce740d03c6, not stripped $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1,4M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc 1021K /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 3,2M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock $ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock 2,3M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock }}} Do we really need to include the debug info for exes? -- Comment: The binaries from https://launchpad.net/~hvr/+archive/ubuntu/ghc are stripped however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 18:35:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 18:35:10 -0000 Subject: [GHC] #9087: Executables in the Linux binaries are not stripped In-Reply-To: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> References: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> Message-ID: <060.c81eaa5a6e8df5757062e6da71388776@haskell.org> #9087: Executables in the Linux binaries are not stripped -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Build System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 20:34:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 20:34:48 -0000 Subject: [GHC] #9784: Improve error message for misplaced quote inside promoted qualified type (was: Allow Qualified Promoted Types) In-Reply-To: <047.546c05d155a967089478b2cd78e20337@haskell.org> References: <047.546c05d155a967089478b2cd78e20337@haskell.org> Message-ID: <062.1ee600d41563fd35a691f695d17e7baf@haskell.org> #9784: Improve error message for misplaced quote inside promoted qualified type -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3155 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request * related: => #3155 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 9 22:00:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Nov 2014 22:00:21 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.abb5ce343892f22e0e07e4594d8a5cfa@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------------+------------------------------ Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.8.1-rc2 Resolution: | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------ Comment (by Ansible): I have not tried 7.8 lately on the PI. I don't know when I'll get back to that, it took me quite a while (days) to compile and I'm no longer developing a haskell project on it. I will give it a try when I get a chance though, on the pcduino perhaps where I can compile ghc on the device itself. Currently ghci does not work on the pcduino, but then its not running 7.8.3 either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 01:06:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 01:06:33 -0000 Subject: [GHC] #9786: Make quot/rem/div/mod with known divisors fast Message-ID: <045.a567cda762cf1c61d5b971fa0a1a7c30@haskell.org> #9786: Make quot/rem/div/mod with known divisors fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC (with NCG) currently optimizes `Int` division by powers of two, but not by other known divisors. The Intel Optimization Manual section 9.2.4 describes a general technique for replacing division by known, sufficiently small, divisors with multiplication. LLVM appears to go further in some fashion. There's no reason we can't do something similar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 02:21:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 02:21:10 -0000 Subject: [GHC] #9786: Make quot/rem/div/mod with known divisors fast In-Reply-To: <045.a567cda762cf1c61d5b971fa0a1a7c30@haskell.org> References: <045.a567cda762cf1c61d5b971fa0a1a7c30@haskell.org> Message-ID: <060.a616b8a15453e98636605181cbf9d86f@haskell.org> #9786: Make quot/rem/div/mod with known divisors fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): It looks like https://gmplib.org/~tege/divcnst-pldi94.pdf is a good source for the algorithms involved. There are algorithms there both for what Haskell calls `quot` and what it calls `div`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 13:16:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 13:16:03 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.cb9121cf63a14f720f7ddc8ee0e9f22c@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Comment (by ross): I've uploaded a new version of transformers incorporating this patch (and some others). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 15:21:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 15:21:07 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.765543cc800d97cf9dfc6d2041e5e6dd@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new * component: Compiler => Template Haskell Comment: I am able to reproduce with 7.8.3 and recent HEAD, on Linux, following these steps: * ghci thbug.hs * ignore the error * comment out the newName, uncomment the mkName in Fun.hs * :r This is the result: {{{ $ ghc-7.9.20141108 --interactive thbug.hs GHCi, version 7.9.20141108: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling Fun ( Fun.hs, interpreted ) [2 of 2] Compiling Main ( thbug.hs, interpreted ) thbug.hs:4:1: Duplicate exact Name ?X? Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but bound it multiple times If that's it, then -ddump-splices might be useful Failed, modules loaded: Fun. ... Comment out the newName, uncomment the mkName in Fun.hs. ... *Fun> :r [1 of 2] Compiling Fun ( Fun.hs, interpreted ) [2 of 2] Compiling Main ( thbug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141108 for x86_64-unknown-linux): kcLookupKind APromotionErr RecDataConPE }}} So the first 'duplicate exact name X' error leaves GHCi in some inconsistent state. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 16:23:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 16:23:39 -0000 Subject: [GHC] #9683: ghc: panic! (the 'impossible' happened) [Cant do annotations without GHCi] In-Reply-To: <048.44005199e43277450218210121321732@haskell.org> References: <048.44005199e43277450218210121321732@haskell.org> Message-ID: <063.45626c7552e605ad18125f037e3fd963@haskell.org> #9683: ghc: panic! (the 'impossible' happened) [Cant do annotations without GHCi] -------------------------------------+------------------------------------- Reporter: jeffmaner | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | #7504,#7824,#8212,#9361 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #7504,#7824,#8212,#9361 Comment: Sorry to hear you ran into this problem. This has been fixed in 7.4.2 (ticket #5839), so you could try upgrading: https://www.haskell.org/ghc/docs/7.4.2/html/users_guide/release-7-4-2.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 16:51:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 16:51:14 -0000 Subject: [GHC] #9666: runtime crashing with +RTS -w -h In-Reply-To: <048.a72435c7d7e08f5f9304d55291b7fcca@haskell.org> References: <048.a72435c7d7e08f5f9304d55291b7fcca@haskell.org> Message-ID: <063.a452b2324893fd563c3a373f11c3ba6f@haskell.org> #9666: runtime crashing with +RTS -w -h -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: (see | description) | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): For reference: {{{ commit 74ee9df9f9e79e7110e9d8541b84010f35c464c5 Author: Simon Marlow Date: Mon Jun 9 17:49:43 2008 +0000 Experimental "mark-region" strategy for the old generation Sometimes better than the default copying, enabled by +RTS -w }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 17:03:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 17:03:54 -0000 Subject: [GHC] #9787: typo in the ghci help : 'simplifed' Message-ID: <046.e548f5d9dbdb099adf5d281f6c83596a@haskell.org> #9787: typo in the ghci help : 'simplifed' -------------------------------------+------------------------------------- Reporter: nicoder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello, I ran `ghci`at the command line and then `:?` and saw a typo in this line : :sprint [ ...] simplifed version of :print (I expected 'simplified' instead of 'simplifed'). Also, the line just above uses the present tense when the other lines use the imperative : :print [ ...] prints a value without forcing its computation A search on github ( https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=simplifed ) tells me the typo is probably still in the project source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 17:06:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 17:06:52 -0000 Subject: [GHC] #9662: stack overflow in type checker In-Reply-To: <046.dd8b7f2f1cb39f3fdbde8cd7b54fa2d7@haskell.org> References: <046.dd8b7f2f1cb39f3fdbde8cd7b54fa2d7@haskell.org> Message-ID: <061.b428bc43b797581a3e42a5dd2616c63b@haskell.org> #9662: stack overflow in type checker -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: I can't find the commit, but this has been fixed in HEAD (ghc-7.9.20141108). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 17:26:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 17:26:26 -0000 Subject: [GHC] #9648: ghci fails to reload after deleting/creating an imported module In-Reply-To: <051.6a800ad064a7e9508a8fdca22e1c117b@haskell.org> References: <051.6a800ad064a7e9508a8fdca22e1c117b@haskell.org> Message-ID: <066.037e910be1743e34faedcaaba11f04f9@haskell.org> #9648: ghci fails to reload after deleting/creating an imported module -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Old description: > If you start GHCi with a 2 module program, delete the child module, > reload, you get an error (as expected). If you recreate the child module > and reload, it reloads the child module but erroneously claims that > parent can't find the child. > > Note that if you rename the child to something else, then rename it back, > then the test works - so it seems the reappearance and the file stamp > confuses ghci. Spotted while working on ghcid: > https://github.com/ndmitchell/ghcid > > {{{ > $ echo module Util where > Util.hs > > $ echo import Util; main = print 1 > Main.hs > > $ ghci Main.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. > [1 of 2] Compiling Util ( Util.hs, interpreted ) > [2 of 2] Compiling Main ( Main.hs, interpreted ) > Ok, modules loaded: Util, Main. > *Main> :!del Util.hs > *Main> :r > > Main.hs:1:8: > Could not find module `Util' > It is a member of the hidden package `ghc-7.8.3'. > Use -v to see a list of the files searched for. > Failed, modules loaded: Util, Main. > *Main> :!echo module Util where > Util.hs > *Main> :r > [1 of 2] Compiling Util ( Util.hs, interpreted ) > [2 of 2] Compiling Main ( Main.hs, interpreted ) [Util > changed] > > Main.hs:1:1: > Failed to load interface for `Util' > It is a member of the hidden package `ghc-7.8.3'. > Use -v to see a list of the files searched for. > Failed, modules loaded: Util. > }}} New description: If you start GHCi with a 2 module program, delete the child module, reload, you get an error (as expected). If you recreate the child module and reload, it reloads the child module but erroneously claims that parent can't find the child. Note that if you rename the child to something else, then rename it back, then the test works - so it seems the reappearance and the file stamp confuses ghci. Spotted while working on ghcid: https://github.com/ndmitchell/ghcid {{{ $ echo module Util where > Util.hs $ echo "import Util; main = print 1" > Main.hs $ ghci Main.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. [1 of 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Util, Main. *Main> :!del Util.hs -- on Linux --> :!rm Utils.hs *Main> :r Main.hs:1:8: Could not find module `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util, Main. *Main> :!echo module Util where > Util.hs *Main> :r [1 of 2] Compiling Util ( Util.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) [Util changed] Main.hs:1:1: Failed to load interface for `Util' It is a member of the hidden package `ghc-7.8.3'. Use -v to see a list of the files searched for. Failed, modules loaded: Util. }}} -- Comment (by thomie): Still present in ghc-7.9.20141108. I edited the description to make it Linux compatible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 19:16:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 19:16:22 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.06e681af92e8d40637a86c09ffbdf296@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): I have updated Phab:D426, Phab:D438 and Phab:D412 to rebase against current master, and to work in the feedback received. They are once more ready for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 19:21:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 19:21:31 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.5fe229e8443dfe7fa42f7905ae2d2b1d@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: I just ran `make` in a clone of the testrepo from comment:12, after installing `primitive-0.5.4` in a cabal sandbox. Results with GHC 7.8.3: {{{ Fast version etas : 0 Slow version etas : 18 }}} Results with GHC 7.9.20141108: {{{ Fast version etas : 0 Slow version etas : 0 }}} So this bug must have been fixed somewhere along the way, although I don't know in which commit. Feel free to reopen if you think this answer is unsatisfactory, or hang tight till the 7.10 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 19:31:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 19:31:00 -0000 Subject: [GHC] #9643: ghci must be restarted to use break point more than once? In-Reply-To: <047.e2345eb95a11ab858ce23f47024eee0d@haskell.org> References: <047.e2345eb95a11ab858ce23f47024eee0d@haskell.org> Message-ID: <062.9aead7f7e6f3c562b89ce493dd1f707a@haskell.org> #9643: ghci must be restarted to use break point more than once? -------------------------------------+------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Thanks for your report. Could you please attach a test file and the steps needed to reproduce your problem, both with the current output and your expected output. See also [wiki:ReportABug]. Please note that GHCi is wholefully understaffed at the moment, so it might take a while before someone takes a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 20:12:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 20:12:58 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.340e6c56c2b72561cfe9abce84ce2f5b@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): Oops, not yet, need to document the annotations per AST element -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 20:13:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 20:13:15 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.2a4c47d54f2704a26cfdb351d2dc782f@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: core-libraries-committee@? (added) Comment: Working on this now... just clarifying that the fix is a breaking change, in that a previous use of GND will no longer work. It happened that this GND appears in the testsuite, test `roles/should_compile/RolesIArray`: {{{ newtype N = MkN Word64 deriving (IArray UArray) }}} With changing the roles on `UArray`, this no longer works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 20:17:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 20:17:23 -0000 Subject: [GHC] #9640: Invalid object in processHeapClosureForDead(): 2130762223 In-Reply-To: <047.4251ac36032806c0b7c6a3cfadb392fc@haskell.org> References: <047.4251ac36032806c0b7c6a3cfadb392fc@haskell.org> Message-ID: <062.78246b5be9946647d2b6f27f07e30c8b@haskell.org> #9640: Invalid object in processHeapClosureForDead(): 2130762223 -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): `yi` does not currently build with ghc HEAD, see https://github.com/yi- editor/yi/issues/705, so I am unable to reproduce this bug at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 20:19:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 20:19:25 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.ede8fbb9bad35d69e93839f95ff26fad@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): In trying to sweep up remaining tickets assigned to me before the feature freeze, I came across this one. In comment:5, I ask for real users who want role annotations for type and/or data families (and/or their respective instances) to do real work -- preferably with an example of said real work. Though two people came out of the woodwork and tried to meet this need, neither one really qualifies: - The example from jwlato requires something fundamentally different from this ticket -- the ability to do representational matching on families. That, essentially, has been moved to #9112. The solution there may also require getting this ticket sorted out, but I don't think this ticket is the blocking issue. - The example from dmmclean is also, by dmmclean's own admission, not applicable here. Fixing this would take several days worth of work, and days are precious. So I'm going to let this one slip unless convinced otherwise. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 20:51:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 20:51:22 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.e9a1fe1335bb827821e78eb18ce50fec@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"87101364e0c2db5e472c6331ad35503028b2ec3c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="87101364e0c2db5e472c6331ad35503028b2ec3c" Move Data.Functor.Identity from transformers to base This also updates the `transformers` submodule to the just released `transformers-0.4.2.0` package version. See #9664 for more details Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D313 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 21:15:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 21:15:21 -0000 Subject: [GHC] #9787: typo in the ghci help : 'simplifed' In-Reply-To: <046.e548f5d9dbdb099adf5d281f6c83596a@haskell.org> References: <046.e548f5d9dbdb099adf5d281f6c83596a@haskell.org> Message-ID: <061.05083e2b8f3b9d25964a75b985ce6716@haskell.org> #9787: typo in the ghci help : 'simplifed' -------------------------------------+------------------------------------- Reporter: nicoder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7ae596af381278dc43b7312d48a18b7cce6e4ab9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7ae596af381278dc43b7312d48a18b7cce6e4ab9" Typo fix; Trac #9787 Also, reword :print description. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 21:15:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 21:15:58 -0000 Subject: [GHC] #9787: typo in the ghci help : 'simplifed' In-Reply-To: <046.e548f5d9dbdb099adf5d281f6c83596a@haskell.org> References: <046.e548f5d9dbdb099adf5d281f6c83596a@haskell.org> Message-ID: <061.3d9b24056d1cce3ec56209391d0ebe1d@haskell.org> #9787: typo in the ghci help : 'simplifed' -------------------------------------+------------------------------------- Reporter: nicoder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Fixed, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 21:20:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 21:20:15 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.679bb60479bc2755d43b6eb8a5dbab23@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Making a note here to look at `:browse` and `:info` in GHCi if/when we implement this. See also #8672. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 21:20:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 21:20:27 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.3e494a34661003c1a1539f66050088c5@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime | Version: System | Keywords: thread-local Resolution: | state, TLS clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: 7678 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by George): Was hoping to have this in the next Haskell Platform. A few months back the patch was coming soon. I assume there were problems. Are we still confident we know how to fix this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 21:21:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 21:21:06 -0000 Subject: [GHC] #8672: :browse and roles on typefamilies In-Reply-To: <047.79fcde45b99494808022df1c15fe6d9a@haskell.org> References: <047.79fcde45b99494808022df1c15fe6d9a@haskell.org> Message-ID: <062.be177053473927f99b4201088e5a6360@haskell.org> #8672: :browse and roles on typefamilies -------------------------------------+------------------------------------- Reporter: monoidal | Owner: goldfire Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Leaving this ticket open doesn't seem to serve a purpose any more. I made a comment on #8177. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 21:36:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 21:36:32 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.531c64c98ca8bcfa0e44af3966e26262@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to be clear, what exactly is "the fix" you mention? * What roles are you proposing for arrays of various sorts? * What goes wrong with the above instance? Is it rejecting a program that is bogus, or is it rejecting a program that "ought" to be ok? Incidentally, I think it should ''definitely'' be part of the contract for `Storable` that `sizeOf` should return the same result for a newtype as for the type it wraps. Thus this would be BAD: {{{ newtype N = MkN T instance Storable T where sizeOf _ = 4 instance Storable N where sizeOf _ = 8 }}} If `N` and `T` are representationally equaly, how could they take a different number of bytes to represent. That should be part of the documentation for `Storable`. I believe this is what Reid was saying in comment:8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 21:43:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 21:43:54 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.804b036807d6acb56b22a5da316e66ad@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jwlato): Just a quick note to verify that goldfire is entirely correct WRT #9112; I agree that my example doesn't have much bearing on this ticket at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 21:49:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 21:49:21 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.995631da59fd27912a6d4c3c83df1816@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): See my WIP commit [https://github.com/ghc/packages- array/commit/86225ba71603ed73a338e5f658698fc87aadcae9 here]. In the end, I have little idea what I'm doing here -- I was just implementing the fix I thought we had agreed on (but never concretely articulated), which is to make the element parameter to all the types mentioned in the initial report have a nominal role. Reid does seem to say in comment:8, upon closer inspection, that `UArray` should keep its representational role. But I'd love for him to chime in here. I'll do what I'm told on this one! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 21:54:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 21:54:45 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.e0b76229a2917c20e2bdbc880c9f4703@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Well I argued in comment:5 for a representational (not nominal!) role; and Reid agreed in comment:8. Specifically, which types are "all the types mentioned in the initial report"? What roles do other array types have? You didn't answer my second question in comment:12. Any thoughts on that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 22:06:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 22:06:48 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.bc0c00eae697b320bbebd4ee19c9e5d4@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 22:07:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 22:07:59 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.0075428750306efd5e0578b10b52bc22@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 22:43:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 22:43:22 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.39349872f3b72ff19bb0d3350b6238e2@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Sorry for missing the second question. If we change roles from representational to nominal, then some uses of GND will no longer type check. This is correct behavior. With `UArray` having its representational role back, the code in comment:11 will type check. I think a fuller answer is that, according to Reid's analysis in comment:3, we don't want to be able to coerce a `StorableArray i Int` to a `StorableArray i Age`, because `Age` and `Int` might have different `Storable` instances. So, if GND fails, that's correct behavior. In any case, I will wait for Reid (or someone else knowledgeable about `array`) to give explicit instructions on what to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 22:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 22:45:32 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.ca529d46c2b13819d7293dd804f7a68b@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:14 simonpj]: > Specifically, which types are "all the types mentioned in the initial report"? What roles do other array types have? {{{ Data.Array.Unboxed.UArray Data.Array.IO.IOUArray Data.Array.ST.STUArray Data.Array.Storable.StorableArray }}} I don't know anything in particular about the roles of other array types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 10 23:07:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Nov 2014 23:07:56 -0000 Subject: [GHC] #9788: `coerce` has an impossible type Message-ID: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ 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 -fprint-explicit-foralls Prelude> :set -fprint-explicit-kinds Prelude> import Data.Coerce Prelude Data.Coerce> :t coerce coerce :: forall (k :: BOX) (a :: k) (b :: k). Coercible k a b => a -> b }}} Are those types `a` and `b` really of kind `k`? They certainly shouldn't be. This is worse in HEAD: GHC panics. (Actually, I think panicking is an improvement.) Easy to fix, happily. Will do so in the course of other work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 00:05:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 00:05:57 -0000 Subject: [GHC] #9789: Make GHC accept .format+lhs as extension for literate haskell files Message-ID: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> #9789: Make GHC accept .format+lhs as extension for literate haskell files -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I proposed this solution on the mailing list as a solution to allowing other tools to determine what the type of the non-haskell content in a literate haskell file is. For example, whether a document is markdown + literate haskell or reStructuredText + literate haskel. There were no real objections on the mailing list and this approach has been tested and works on Windows. Last discussion: https://www.haskell.org/pipermail/glasgow-haskell- users/2014-August/025228.html Initial discussion: https://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024745.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 00:07:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 00:07:31 -0000 Subject: [GHC] #9790: Produce coercion rules for derived Functor instances Message-ID: <045.8a527e88bca622461eac96735db65516@haskell.org> #9790: Produce coercion rules for derived Functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: coercion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I don't ''think'' we do this yet, but I think we probably can. If we derive a `Functor` instance, we should, whenever possible and valid, produce some sort of `fmap coerce = coerce` rule for that type. This is done manually for lists in `GHC.Base`, but I imagine it probably applies (much) more generally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 01:34:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 01:34:44 -0000 Subject: [GHC] #9790: Produce coercion rules for derived Functor instances In-Reply-To: <045.8a527e88bca622461eac96735db65516@haskell.org> References: <045.8a527e88bca622461eac96735db65516@haskell.org> Message-ID: <060.a4cce715aae888849c2e2eda62b396c4@haskell.org> #9790: Produce coercion rules for derived Functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: coercion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Such a rule is wrong for non-lawful functors, which is why we haven't done it. It would be nice (perhaps even very nice) if we could give users a way to say that a particular instance is lawful w.r.t. the appropriate laws and would allow magic like the proposed idea. However, I'm not volunteering to design and/or implement such a system... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 01:40:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 01:40:38 -0000 Subject: [GHC] #9790: Produce coercion rules for derived Functor instances In-Reply-To: <045.8a527e88bca622461eac96735db65516@haskell.org> References: <045.8a527e88bca622461eac96735db65516@haskell.org> Message-ID: <060.97f04eb392199ebe6ce3e5d9da1bfba0@haskell.org> #9790: Produce coercion rules for derived Functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: coercion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 goldfire]: > Such a rule is wrong for non-lawful functors, which is why we haven't done it. > > It would be nice (perhaps even very nice) if we could give users a way to say that a particular instance is lawful w.r.t. the appropriate laws and would allow magic like the proposed idea. However, I'm not volunteering to design and/or implement such a system... Right, that's why I only mentioned ''derived'' `Functor` instances. Surely a derived instance that does not depend on any non-derived instances should be lawful! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 01:54:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 01:54:17 -0000 Subject: [GHC] #9790: Produce coercion rules for derived Functor instances In-Reply-To: <045.8a527e88bca622461eac96735db65516@haskell.org> References: <045.8a527e88bca622461eac96735db65516@haskell.org> Message-ID: <060.90e80782959932fb71e0589aa8579e42@haskell.org> #9790: Produce coercion rules for derived Functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: coercion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Ah -- I missed the word "derive". But, unfortunately, this still doesn't pan out in all cases: {{{ data BadFunctor a = MkBF a a deriving Show instance Functor BadFunctor where fmap f (MkBF x _) = MkBF (f x) (f x) data Wrapped f a = MkW (f a) deriving (Functor, Show) }}} `Wrapped` has a derived `Functor` instance, and yet `fmap id (MkW (MkBF True False))` is not the same as `id (MkW (MkBF True False))`. I do think your idea is sound as long as the derived `Functor` instance has no constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:10:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:10:43 -0000 Subject: [GHC] #9791: Ghc panics on tiny example, naive try to overload compose Message-ID: <046.95e2b024febbe58ed8cb25a6bf120db7@haskell.org> #9791: Ghc panics on tiny example, naive try to overload compose -------------------------------------+------------------------------------- Reporter: camarao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: Overloading | Operating System: Linux Architecture: x86 | Type of failure: Compile- Difficulty: Easy (less than 1 | time crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- {-# LANGUAGE MultiParamTypeClasses #-} class Compose a b c e f where (<.>)::(b -> c)->(a -> e)->(a -> f) instance Compose a b c b c where (<.>) = (.) instance Monad m -> Compose a b c (m b) (m c) where (<.>) f g a = g a >>= (return . f) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:32:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:32:23 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.ec3a096d82eaf26b0ee890f05fa82e9e@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: GHCi | Version: 6.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: hvr (added) * failure: => None/Unknown Comment: #8427 is related; this ticket is basically the GHCi variant of the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:34:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:34:02 -0000 Subject: [GHC] #8427: GHC accepts invalid program because of EPS poisoning In-Reply-To: <044.8d7cfe02b3e4ed540e00001a8151e1c6@haskell.org> References: <044.8d7cfe02b3e4ed540e00001a8151e1c6@haskell.org> Message-ID: <059.099b009a7a226e6a3aa1439c5b57d70a@haskell.org> #8427: GHC accepts invalid program because of EPS poisoning -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: GHC | than a day) accepts invalid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate Comment: Duplicate of #2182 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:35:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:35:20 -0000 Subject: [GHC] #9788: `coerce` has an impossible type In-Reply-To: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> References: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> Message-ID: <062.b50e2f0364a406d91d073bf63f0edd44@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D468 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D468 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:35:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:35:46 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.c855b950cdb870d2f6bf3adb535341c1@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D469 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D469 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:37:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:37:12 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire Message-ID: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I write a nice, simple use, like: {{{#!hs myPotato = map coerce }}} or even {{{#!hs myPotato = Data.OldList.map coerce }}} the "`map/coerce`" rule does not fire. It looks like there are two things getting in the way: 1. The `map` rule fires first, turning `map` into a `build/foldr` form, which `map/coerce` does not recognize. 2. Even if `map` gets written back, `coerce` has been expanded into something the rule doesn't recognize. So we end up with something that looks like {{{#!hs myPotato = \ (@ a_are) (@ b_arf) ($dCoercible_arz :: Coercible a_are b_arf) (lst_aqx :: [a_are]) -> map @ a_are @ b_arf (\ (tpl_B2 [OS=ProbOneShot] :: a_are) -> case $dCoercible_arz of _ [Occ=Dead] { GHC.Types.MkCoercible tpl1_B3 -> tpl_B2 `cast` (tpl1_B3 :: a_are ~R# b_arf) }) lst_aqx }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:42:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:42:31 -0000 Subject: [GHC] #9791: Ghc panics on tiny example, naive try to overload compose In-Reply-To: <046.95e2b024febbe58ed8cb25a6bf120db7@haskell.org> References: <046.95e2b024febbe58ed8cb25a6bf120db7@haskell.org> Message-ID: <061.4755e46549fe29bcaf8dd25d9505edec@haskell.org> #9791: Ghc panics on tiny example, naive try to overload compose -------------------------------------+------------------------------------- Reporter: camarao | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Overloading Operating System: Linux | Architecture: x86 Type of failure: Compile- | Difficulty: Easy (less than 1 time crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: #5951 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #5951 Comment: Thank you for the report. This has been fixed, try upgrading to GHC 7.6 or 7.8. {{{ $ ghc-7.6.3 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:9:10: Malformed instance: Monad m -> Compose a b c (m b) (m c) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:44:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:44:26 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.835002cc0b64de62288efacd8c245bc2@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: low => normal * failure: None/Unknown => GHC accepts invalid program * component: GHCi => Compiler (Type checker) * milestone: ? => 7.10.1 Old description: > {{{ > $ compiler/stage2/ghc-inplace --interactive > GHCi, version 6.9.20080317: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> :i Functor > class Functor f where fmap :: (a -> b) -> f a -> f b > -- Defined in GHC.Base > instance Functor Maybe -- Defined in Data.Maybe > instance Functor [] -- Defined in GHC.Base > instance Functor IO -- Defined in GHC.IOBase > Prelude> fmap not (True,True) > > :1:0: > No instance for (Functor ((,) Bool)) > arising from a use of `fmap' at :1:0-19 > Possible fix: add an instance declaration for (Functor ((,) Bool)) > In the expression: fmap not (True, True) > In the definition of `it': it = fmap not (True, True) > Prelude> :m +Data.Array > Prelude Data.Array> :i Functor > class Functor f where fmap :: (a -> b) -> f a -> f b > -- Defined in GHC.Base > instance (Ix i) => Functor (Array i) -- Defined in GHC.Arr > instance Functor ((->) r) -- Defined in Control.Monad.Instances > instance Functor ((,) a) -- Defined in Control.Monad.Instances > instance Functor (Either a) -- Defined in Control.Monad.Instances > instance Functor Maybe -- Defined in Data.Maybe > instance Functor [] -- Defined in GHC.Base > instance Functor IO -- Defined in GHC.IOBase > Prelude Data.Array> fmap not (True,True) > (True,False) > Prelude Data.Array> :m -Data.Array > Prelude> :i Functor > class Functor f where fmap :: (a -> b) -> f a -> f b > -- Defined in GHC.Base > instance Functor ((->) r) -- Defined in Control.Monad.Instances > instance Functor ((,) a) -- Defined in Control.Monad.Instances > instance Functor (Either a) -- Defined in Control.Monad.Instances > instance Functor Maybe -- Defined in Data.Maybe > instance Functor [] -- Defined in GHC.Base > instance Functor IO -- Defined in GHC.IOBase > Prelude> fmap not (True,True) > (True,False) > }}} New description: The EPS (external-package state) is only ever increased, never decreased between compilation of different modules in a single batch compilation or GHCi session. Example 1 (GHCi): {{{ ezyang at sabre:~/Dev/labs/ezyangest$ ghci 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> (\x -> x) :2:1: No instance for (Show (t0 -> t0)) arising from a use of `print' Possible fix: add an instance declaration for (Show (t0 -> t0)) In a stmt of an interactive GHCi command: print it Prelude> :m +Text.Show.Functions Prelude Text.Show.Functions> (\x -> x) Prelude Text.Show.Functions> :m -Text.Show.Functions Prelude> :r Ok, modules loaded: none. Prelude> (\x -> x) }}} Example 2 (make): {{{ ezyang at sabre:~/Dev/labs/ezyangest$ cat A.hs module A where import Text.Show.Functions ezyang at sabre:~/Dev/labs/ezyangest$ cat B.hs module B where y = show (\x -> x) ezyang at sabre:~/Dev/labs/ezyangest$ ghc --make B.hs A.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) ezyang at sabre:~/Dev/labs/ezyangest$ ghc --make A.hs B.hs -fforce-recomp [1 of 2] Compiling B ( B.hs, B.o ) B.hs:2:5: No instance for (Show (t0 -> t0)) arising from a use of `show' Possible fix: add an instance declaration for (Show (t0 -> t0)) In the expression: show (\ x -> x) In an equation for `y': y = show (\ x -> x) }}} -- Comment: I updated the bug description with some modernized, simpler test-cases. simonpj and I have chatted about this and we have a new, improved plan of attack to solve the problem: 1. We'll maintain a set of loaded interface files in the type-checking environment. When an interface file is loaded, we add it to this set. 2. When a type class instance lookup is performed, IF the instance is an orphan, we'll also check if the interface file which defined the instance is in the loaded set. If it is not, we pretend it doesn't exist. I have most of a patch to solve this but I have to shake out a bug where GHCi is not preserving the set of loaded interfaces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:54:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:54:12 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.712462d27b98cfabe5bf063918cd85ca@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think the `map` rewrite probably isn't a big problem, because if `map` fuses with anything, the mapped coercion will become free (if a mapped coercion fuses with another mapped coercion, those will end up a mapped composed coercion?that might need some special treatment, but I'm not sure). The expansion of `coerce`, however, which seems to relate to the fact that `Coercible` has only one member, looks problematic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 02:56:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 02:56:27 -0000 Subject: [GHC] #9790: Produce coercion rules for derived Functor instances In-Reply-To: <045.8a527e88bca622461eac96735db65516@haskell.org> References: <045.8a527e88bca622461eac96735db65516@haskell.org> Message-ID: <060.28288a26fc363bf43dd44d0c6c1bd3a8@haskell.org> #9790: Produce coercion rules for derived Functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: coercion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 goldfire]: > I do think your idea is sound as long as the derived `Functor` instance has no constraints. That's what I was trying to get at with the bit about not depending on non-derived `Functor` instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 04:45:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 04:45:08 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.36d8ed85d1844650993b73f12369d1f9@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * version: 7.8.1 => 7.9 * milestone: ? => 7.10.1 Comment: Setting milestone per Reid Barton. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 06:13:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 06:13:08 -0000 Subject: [GHC] #9786: Make quot/rem/div/mod with known divisors fast In-Reply-To: <045.a567cda762cf1c61d5b971fa0a1a7c30@haskell.org> References: <045.a567cda762cf1c61d5b971fa0a1a7c30@haskell.org> Message-ID: <060.3795f99285ec67a54cecd25be09c02d8@haskell.org> #9786: Make quot/rem/div/mod with known divisors fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): The more I think about it, the more likely it seems that we should `NOINLINE` `divMod` and `quotRem` until very, very late, or maybe never inline them. There are two reasons for this: 1. We would prefer to snag them unmodified when we recognize known divisors. 2. As described in #9617, it would be very nice to use CSE to merge `div` with `mod` and `quot` with `rem` automatically. The major complication, of course, is that in the case of an ''unknown'' divisor that is used multiple times, we'd like to avoid repeating the sign test. I still have no clear sense of how to resolve the tension between these desires. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 07:21:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 07:21:15 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.20a8fadbf855e8373d70cfac276ae3d8@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): unboxed should DEFINITELY have representational (because the heap representation of a newtyped value is guaranteed to be the saem). I think thats pretty clearly what Reid was articulating earlier, and that Storable arrays (because of the possible non uniform storable sizes) *might* be a candidate wrt off heap data, BUT that the argument might be weaker for that. Though i could be recalling this whole thing wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 07:22:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 07:22:34 -0000 Subject: [GHC] #9781: Make list monad operations fuse In-Reply-To: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> References: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> Message-ID: <060.35b3458feab8ce1804049e39aebb0545@haskell.org> #9781: Make list monad operations fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D455 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"4923cea56345060faaf77e4c475eac6aa3c77506/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4923cea56345060faaf77e4c475eac6aa3c77506" Define list monad operations using comprehensions Define list monad operations using list comprehensions. Code using monad operations with lists did not fuse fully. Writing list code with `do` notation or `(>>=)` and `(>>)` operations could allocate more than equivalent code using list comprehensions. Define `mapM` directly, instead of using `sequence` and `map`. This leads to substantially less allocation in `cryptarithm2`. Addresses #9781 Reviewed By: ekmett, nomeata Differential Revision: https://phabricator.haskell.org/D455 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 08:51:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 08:51:59 -0000 Subject: [GHC] #9781: Make list monad operations fuse In-Reply-To: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> References: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> Message-ID: <060.c1354b729002f9c4f5a5ba908d2b46f1@haskell.org> #9781: Make list monad operations fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D455 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: This showed some minor performance improvements, and one huge one, as you noticed already: cryptarithm2?s allocation went down by more than 50%! (I just spent a few minutes looking for list monad operations in that benchmark until I noticed that your commit also had an unrelated(?) change to mapM.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 09:06:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 09:06:35 -0000 Subject: [GHC] #9788: `coerce` has an impossible type In-Reply-To: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> References: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> Message-ID: <062.7efdc197000ab765c9beb3229b698ced@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D468 | -------------------------------------+------------------------------------- Comment (by nomeata): My bad, due to insufficient knowledge about the kind system. Thanks for cleaning up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 09:17:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 09:17:58 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.a9dd787648d3fe535bf4a5df448d9c26@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): We have a test case for this, T2110. I wonder why you observe something different. My guess: Your code is polymorphic in the member of the list, and hence the code looks different and is no longer matched. Now if GHC would float out the `case $dCoercible_arz of`, it would probably work. But of course it cannot, or we?d be stricter in the `Coercible` constraint than intended. Ah: And in the polymorphic case, `map coerce = coerce` does not even hold! If the `Coercible` evidence is ?, then `map coerce [] = []`, but `coerce [] = ?`. Given that high performance code is rarely polymorphic, I think we are fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 09:56:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 09:56:09 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.8eb8d08032d847c2737a3cc212dc6692@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's my summary * Plan A: * If an unboxed array of `Age` stores (unboxed) ages in a 16-bit field, but an unboxed array of `Int` stores (unboxed) ints in a 32-bit field, then it would be wrong to coerce from unboxed-array-of-`Age` to unboxed- array-of-`Int`. (The field width is described by `sizeOf` in the `Storable` class.) * This is not an unreasonable scenario. Perhaps you invented the newtype precisely because ages have a narrower range of values than ints. * In that case, unboxed arrays should have nominal role for their element type, and the GND example in comment:11 should rightfully fail. * Plan B: * An alternative is to insist that the `sizeOf` method should yield the same result for a newtype as for its underlying representation type. * Then a representational role for the element type would be justified. * Which would allow more expressive coercions; notably the GND in comment:11 I was originally voting for Plan B. But (a) it relies on an unenforced user convention about `Storable` instances, and (b) there are reasonable situations in which you might want a different width for a newtype. So on reflection I think Plan A is probably right. If we adopt it, we should add a digest of this thread (e.g. the above Plan A/B notes) as a Note with the role declaration. The core-libraries committee is already cc'd. Edward, we need a decision for 7.10. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 09:57:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 09:57:42 -0000 Subject: [GHC] #9788: `coerce` has an impossible type In-Reply-To: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> References: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> Message-ID: <062.d5ae201efac0448cdafb0b03f7203bd2@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D468 | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest Comment: I have no idea how this happens, but thank you for fixing it (for 7.10). Can you also add a regression test? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 10:07:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 10:07:31 -0000 Subject: [GHC] #9788: `coerce` has an impossible type In-Reply-To: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> References: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> Message-ID: <062.00797f222c1b591fd42522eda3cfea35@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D468 | -------------------------------------+------------------------------------- Comment (by nomeata): It was commit 2f3ea95285d0cccc2a999e7572d8fb78dc2ea441 that made this type signature issue visible. Note that you even updated the users guide with this particular example, so I guess you?ll need to find one that is not horribly wrong :-). The original cause was 976a1087ae75accb4ad9d869d14641b2581c1606 implementing #8541. I back then just assumed that if `Coercible` has to be higher-kinded, then `coerce` has to be too. I guess I was wrong... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 10:36:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 10:36:09 -0000 Subject: [GHC] #7220: Confusing error message in type checking related to type family, fundep, and higher-rank type In-Reply-To: <047.9717070c95e8f3c062d13d9d4af61725@haskell.org> References: <047.9717070c95e8f3c062d13d9d4af61725@haskell.org> Message-ID: <062.c25e4cfdea970b867e894a78a870c2d6@haskell.org> #7220: Confusing error message in type checking related to type family, fundep, and higher-rank type -------------------------------------+------------------------------------- Reporter: tsuyoshi | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1-rc1 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T7220 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard's fix for #9404 makes this compile. He says: The reason this went wrong before is that the old method of inferring a type would get caught when unifying a `TauTv` (the metavariable given as the guess for `f`'s type) with a polytype, deferring to the solver. If we defer, then we don't have enough information to type-check `u` successfully, and we fail. With the new inferring types with `PolyTv`, no deferring happens, and `u` type-checks fine. But with the #9404 fix, `f` is inferred to have the type as given. Then, `u` is checked (by `tcPolyExprNC`) to have the argument type of `f`, which it does. No problems. I actually think that success is the right behavior here, so I chalk this up to a success of this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 10:40:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 10:40:48 -0000 Subject: [GHC] #9640: Invalid object in processHeapClosureForDead(): 2130762223 In-Reply-To: <047.4251ac36032806c0b7c6a3cfadb392fc@haskell.org> References: <047.4251ac36032806c0b7c6a3cfadb392fc@haskell.org> Message-ID: <062.65a3712bcc137fb29ce651d25a593f89@haskell.org> #9640: Invalid object in processHeapClosureForDead(): 2130762223 -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Profiling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 11:36:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 11:36:46 -0000 Subject: [GHC] #9662: stack overflow in type checker In-Reply-To: <046.dd8b7f2f1cb39f3fdbde8cd7b54fa2d7@haskell.org> References: <046.dd8b7f2f1cb39f3fdbde8cd7b54fa2d7@haskell.org> Message-ID: <061.decf33e39f8134aa11e6cf610edd9b9f@haskell.org> #9662: stack overflow in type checker -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: indexed- | types/should_fail/T9662 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_fail/T9662 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 11:46:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 11:46:28 -0000 Subject: [GHC] #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. In-Reply-To: <048.bf4e6160222a10b78f2f4ca8e5795447@haskell.org> References: <048.bf4e6160222a10b78f2f4ca8e5795447@haskell.org> Message-ID: <063.5e3693cc8f09c630f693d3db69218fb3@haskell.org> #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. -------------------------------------+------------------------------------- Reporter: Westycoot | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: worksforme | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | rename/should_fail/T9077 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T9077 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:01:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:01:17 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.14711a835c1a03931bf4a26940eeb32e@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): But I thought `Coercible` evidence is ''never'' ?... unless you're thinking about deferred type errors? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:02:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:02:39 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.b805a71a9fd40e4eeaeada642af24394@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > But I thought Coercible evidence is never ?... unless you're thinking about deferred type errors? It can be ?, just write `coerceWith undefined` using Data.Type.Coercion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:06:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:06:05 -0000 Subject: [GHC] #7862: Could not deduce (A) from the context (A, ...) In-Reply-To: <045.77e996083183797ec6c495029488c3f8@haskell.org> References: <045.77e996083183797ec6c495029488c3f8@haskell.org> Message-ID: <060.9d9cb4ef66dac5bc3e918cda5e17a841@haskell.org> #7862: Could not deduce (A) from the context (A, ...) -------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: indexed- | types/should_compile/T7862 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T7862 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:06:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:06:45 -0000 Subject: [GHC] #9788: `coerce` has an impossible type In-Reply-To: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> References: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> Message-ID: <062.803bb3f515d5582ebba022683f6dbc81@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D468 | -------------------------------------+------------------------------------- Comment (by goldfire): Will update the manual. Does this really need a regression test? I think of this mistake as only a small step above a basic typo. I'm just shocked that we haven't run into this until now! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:10:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:10:06 -0000 Subject: [GHC] #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. In-Reply-To: <048.bf4e6160222a10b78f2f4ca8e5795447@haskell.org> References: <048.bf4e6160222a10b78f2f4ca8e5795447@haskell.org> Message-ID: <063.2d9ae1fd0c72dea86a19a0d2bd5a1162@haskell.org> #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. -------------------------------------+------------------------------------- Reporter: Westycoot | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: worksforme | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | rename/should_fail/T9077 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"13817f06bc8065476711451307039387e3e34576/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="13817f06bc8065476711451307039387e3e34576" Test Trac #9077 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:10:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:10:06 -0000 Subject: [GHC] #9662: stack overflow in type checker In-Reply-To: <046.dd8b7f2f1cb39f3fdbde8cd7b54fa2d7@haskell.org> References: <046.dd8b7f2f1cb39f3fdbde8cd7b54fa2d7@haskell.org> Message-ID: <061.7829f2599633c7d8cbaa4a6ca1a0a12e@haskell.org> #9662: stack overflow in type checker -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: indexed- | types/should_fail/T9662 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ed57ea499958824e82c111bd53a69129a8178659/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ed57ea499958824e82c111bd53a69129a8178659" Test Trac #9662 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:10:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:10:06 -0000 Subject: [GHC] #7862: Could not deduce (A) from the context (A, ...) In-Reply-To: <045.77e996083183797ec6c495029488c3f8@haskell.org> References: <045.77e996083183797ec6c495029488c3f8@haskell.org> Message-ID: <060.31700b7a0e43e61719463c7b1b79467a@haskell.org> #7862: Could not deduce (A) from the context (A, ...) -------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: indexed- | types/should_compile/T7862 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2b67b8f9b259c95ef9394c3a8ff801dc00e968d9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2b67b8f9b259c95ef9394c3a8ff801dc00e968d9" Test Trac #7862 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:10:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:10:41 -0000 Subject: [GHC] #9788: `coerce` has an impossible type In-Reply-To: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> References: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> Message-ID: <062.cae68b1e3bc63e554a7d1622805f5749@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D468 | -------------------------------------+------------------------------------- Comment (by simonpj): OK..no test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:14:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:14:29 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms Message-ID: <045.e251d4b7f57881692430bb7253319357@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: pattern synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | None/Unknown hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Currently all as-patterns are rejected in pattern synonym definitions, to avoid situations like {{{ pattern P x y <- x@(y:_) }}} since there's no valid reason to be able to then write something like {{{ f [True] False = ... }}} this would just lead to confusion. However, I think we could accept as-patterns where the body of the as- pattern doesn't contain any variable bindings that are accessible via the pattern synonym. In other words, this should be OK: {{{ pattern P x <- x@(y:_) }}} since it's exactly equivalent to {{{ pattern P x <- x@(_:_) }}} which I don't think is as confusing as the other example. I haven't really made up my mind yet if these should be bidirectional; but they certainly could be, by just ignoring the body of the as-pattern in the wrapper; so the following two would be equivalent: {{{ pattern P1 x = [x@(y:_)] pattern P2 x <- [x@(y:_)] where P2 x = [x] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:25:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:25:09 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.a43ddc7b94859f8b07ffd9c14b69afbf@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): But that won't have a ? `Coercible` evidence -- that will fail trying to get the `Coercible` evidence in the first place. Or am I confused? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:37:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:37:58 -0000 Subject: [GHC] #9789: Make GHC accept .format+lhs as extension for literate haskell files In-Reply-To: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> References: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> Message-ID: <060.614245cbbc7d90cf476507fbec39326e@haskell.org> #9789: Make GHC accept .format+lhs as extension for literate haskell files -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Some hopefully constructive comments: * This proposal could use a [wiki:WorkingConventions/AddingFeatures wiki page] I think. It would describe the problem being addressed, the different proposals that were made, and why this solution was chosen (accepting `.format+lhs` as a file extension). * Maybe some combination of `-o` and [https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/modes.html #overriding-suffixes -x] command line options could be used to get the same effect? * This [https://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024757.html mail] (proposing `.hs.format`) and [https://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024747.html this one] (prososing a textual fingerprint in the module itself) never got a reply. * How does this feature interact with [https://www.haskell.org/ghc/docs/latest/html/users_guide/separate- compilation.html boot files]: "Currently, if you use a literate source file A.lhs you must also use a literate boot file, A.lhs-boot; and vice versa." * How does this change affect other compilers (JHC was mentioned)? * Would this change need to go into a feature language report? Is it a language feature, does it need a flag? (I'm just trying to think if this change is a big deal or not, maybe I am overthinking things.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 13:51:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 13:51:21 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.f42e8399c740fde732d8bc4bccf38631@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): I was confused. I thought for a moment that the type of `$dCoercible_arz`, i.e. `Coercible` is the same as the `Coercion` thingy, and the latter can be undefined. But they are not, `Coercion` adds another box around `Coercible`, I guess we avoid `Coercion` to be undefined. But `Coercible` is a lifted type, so I?m not sure that we can guarantee that there is no way to produce a bottom here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 14:56:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 14:56:29 -0000 Subject: [GHC] #9789: Make GHC accept .format+lhs as extension for literate haskell files In-Reply-To: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> References: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> Message-ID: <060.dc2e3ff6075bc103588fe603309ce06e@haskell.org> #9789: Make GHC accept .format+lhs as extension for literate haskell files -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Some more points: * Does this break any tools that expect a "normal" file extension (i.e. file.lhs), like maybe Github's [https://github.com/github/linguist linguist]? * Would `filepath` need to be made aware of this change? Currently: {{{ System.FilePath> takeExtension "file.format+lhs" ".format+lhs" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 15:20:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 15:20:06 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.e876acea73f28e9bd415fd64c43284ac@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Depends on the meaning of "guarantee". You're right in that `Coercible` is lifted and can therefore, in theory, contain ?. However, as I understand it, we do some work to avoid ever creating ? here. This is why we track stack depths (or some such) in the solver, right? Another way to say this is that we've designed the solver to avoid creating a ? `Coercible`. So, if by "guarantee", we mean "If GHC is a bug-free implementation of its specification, then there are no ? `Coercible`s", I think we're close. I believe the situation here is very close to that of `~`, which is a lifted type but is supposedly never ?. We're not quite there because of deferred type errors, which surely can create ? `Coercible`s. But I'm personally OK with wonky semantics in this case, if the wonky semantics means real-world speedups in the vastly more common no-deferred-type-errors case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 16:00:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 16:00:56 -0000 Subject: [GHC] #9625: ghc: panic using --enable-executable-dynamic In-Reply-To: <051.41ace47270d90cc9e836ab3706638147@haskell.org> References: <051.41ace47270d90cc9e836ab3706638147@haskell.org> Message-ID: <066.e3d16f4dfe2fd9e0c4a26c0f9357fc7b@haskell.org> #9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: | Owner: CoreyOConnor | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Package | Keywords: system | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Compile- | time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ezyang (added) * component: Compiler => Package system Old description: > (from: https://github.com/haskell/cabal/issues/2039) > > Using --enable-executable-dynamic leads to a ghc panic. > > Reproduction steps: > > 1. clone https://github.com/coreyoconnor/executable-dynamic-issue > 2. cabal configure --enable-tests --enable-executable-dynamic > 3. cabal test > > Expected results: Test executes and passes. > > Actual results: > > {{{ > ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64 > -unknown-linux): Don't understand library name verify-foo > }}} > > Actual results varies based on the name of "verify-foo" test suite. Other > names tried: "verifyFoo", "VerifyFoo". All of which also fail. > > Removing "--enable-executable-dynamic" results in a pass regardless of > test suite name. > > Reproduced on GHC 7.8.2, GHC 7.8.3, Cabal 1.18, Cabal 1.20. Ubuntu. New description: (from: https://github.com/haskell/cabal/issues/2039) Using --enable-executable-dynamic leads to a ghc panic. Reproduction steps: {{{ 1. git clone https://github.com/coreyoconnor/executable-dynamic-issue 2. cabal configure --enable-tests --enable-executable-dynamic 3. cabal test }}} Expected results: Test executes and passes. Actual results: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64 -unknown-linux): Don't understand library name verify-foo }}} Actual results varies based on the name of "verify-foo" test suite. Other names tried: "verifyFoo", "VerifyFoo". All of which also fail. Removing "--enable-executable-dynamic" results in a pass regardless of test suite name. Reproduced on GHC 7.8.2, GHC 7.8.3, Cabal 1.18, Cabal 1.20. Ubuntu. -- Comment: I ran into other problems trying to reproduce this with ghc HEAD, but can confirm the bug exists in 7.8.3 (and 7.8.3.20141105). Here's a slightly simplified testcase: {{{ #!haskell $ cat foo.cabal name: foo version: 0.1.0.0 build-type: Simple cabal-version: >=1.8 Library Test-Suite bar type: detailed-0.9 test-module: Test build-depends: foo, base, Cabal $ cat Setup.hs import Distribution.Simple main = defaultMain $ cat Test.hs module Test where import Distribution.TestSuite tests :: IO [Test] tests = return [] $ cabal configure --enable-tests --enable-executable-dynamic Resolving dependencies... Configuring foo-0.1.0.0... $ cabal build Building foo-0.1.0.0... Preprocessing library foo-0.1.0.0... In-place registering foo-0.1.0.0... Preprocessing test suite 'bar' for foo-0.1.0.0... [1 of 1] Compiling Test ( Test.hs, dist/build/Test.o ) In-place registering bar-0.1.0.0... [1 of 1] Compiling Main ( dist/build/barStub/barStub- tmp/barStub.hs, dist/build/barStub/barStub-tmp/Main.dyn_o ) Linking dist/build/barStub/barStub ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Don't understand library name bar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 16:14:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 16:14:46 -0000 Subject: [GHC] #9621: New Data.Foldable methods In-Reply-To: <042.d9d7ae0716ad2c4184a4d3189309853b@haskell.org> References: <042.d9d7ae0716ad2c4184a4d3189309853b@haskell.org> Message-ID: <057.05ba30a19f8dfc083b827d8f62fdb146@haskell.org> #9621: New Data.Foldable methods -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9586 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 16:24:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 16:24:57 -0000 Subject: [GHC] #9619: HPC Code Coverage complains when two exactly the same mix files are on the path In-Reply-To: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> References: <045.d6a8a743042386a24100f186a6f9b896@haskell.org> Message-ID: <060.6e50e93271bb7069388f8d4194500ae8@haskell.org> #9619: HPC Code Coverage complains when two exactly the same mix files are on the path -------------------------------------+------------------------------------- Reporter: Kasper | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Code | Version: 7.8.3 Coverage | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Thank you for the report. Could you add attach the files needed to reproduce the problem, with instructions on how to run them, and the current and expected output. Please note that hpc hasn't seen any updates in a long time, so it might take a while for someone to take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 16:33:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 16:33:16 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.484cfaba4c7e716ff6c777a313dbeedc@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Tracking the stack depths is to avoid generating looping code at runtime. But we don?t have this guarantee in Core, and the desugarer + typechecker is too large a beast to give any guarantees besides best-effort, I?d say. Maybe it is possible to abstract over the constraints somehow, and write a constraint with value ? in the general case, circumventing any special casing for Coercible? (But even if it is possible it includes so much malice that whoever does that waives any right to complain about `map coerce = coerce` :-)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 16:55:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 16:55:57 -0000 Subject: [GHC] #9781: Make list monad operations fuse In-Reply-To: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> References: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> Message-ID: <060.e02117e1ea34721d6f7fa039c1b55499@haskell.org> #9781: Make list monad operations fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D455 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:5 nomeata]: > This showed some minor performance improvements, and one huge one, as you noticed already: cryptarithm2?s allocation went down by more than 50%! > > (I just spent a few minutes looking for list monad operations in that benchmark until I noticed that your commit also had an unrelated(?) change to mapM.) The change also improves cryptarithm2 without the `mapM` change, but not as much. So there must have been something else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 17:29:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 17:29:02 -0000 Subject: [GHC] #9789: Make GHC accept .format+lhs as extension for literate haskell files In-Reply-To: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> References: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> Message-ID: <060.05da719bc8e3b6122ef7b0a748b86209@haskell.org> #9789: Make GHC accept .format+lhs as extension for literate haskell files -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by merijn): Thanks for the comments. Replying to [comment:1 thomie]: > * This proposal could use a [wiki:WorkingConventions/AddingFeatures wiki page] I think. It would describe the problem being addressed, the different proposals that were made, and why this solution was chosen (accepting `.format+lhs` as a file extension). Given the lack of objection the two times this was raised on the mailing list and the triviality of the implementation, I didn't think a separate write-up was necessary, but I'll add one and raise this again on the mailing list. > * Maybe some combination of `-o` and [https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/modes.html #overriding-suffixes -x] command line options could be used to get the same effect? This seems like it'd be tricky if people have repositories containing files with different content and in general a bit of a hassle, but it would probably work. > * This [https://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024757.html mail] (proposing `.hs.format`) and [https://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024747.html this one] (prososing a textual fingerprint in the module itself) never got a reply. Hmm, you're right that .lhs.format should work, since the lack of .lhs suffix should avoid it from colliding with JHC's naming. I don't think the textual fingerprint in the module itself is a good option, as not all formats may allow for this. > * How does this feature interact with [https://www.haskell.org/ghc/docs/latest/html/users_guide/separate- compilation.html boot files]: "Currently, if you use a literate source file A.lhs you must also use a literate boot file, A.lhs-boot; and vice versa." As-is I was simply planning to map the boot file for "lhs+md" to "lhs+md- boot". > * How does this change affect other compilers (JHC was mentioned)? The report does not specify any specific way of mapping modules to filenames and as such there is no way to make name resolution portable across compilers anyway. My initial email suggested standardising/formalising naming in the report, but this was not taken up. > * Would this change need to go into a feature language report? Is it a language feature, does it need a flag? (I'm just trying to think if this change is a big deal or not, maybe I am overthinking things.) See previous point, the report explicitly does *not* specify the naming of files/modules and as such GHC can implement whatever it likes. Replying to [comment:2 thomie]: > * Does this break any tools that expect a "normal" file extension (i.e. file.lhs), like maybe Github's [https://github.com/github/linguist linguist]? I would not call this "breaking tools" as the old .lhs extension will remain supported by GHC. I would merely say that not all tools may immediately *support* this new format. However, it seems unlikely tools will change to match a format until GHC implements (i.e., chicken and egg problem). I think GHC should just implement a solution that will be easy for other tools to follow. > * Would `filepath` need to be made aware of this change? Currently: > {{{ > System.FilePath> takeExtension "file.format+lhs" > ".format+lhs" > }}} No, I consider ".format+lhs" to be the extension. This would only change the way GHC searched for modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 18:07:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 18:07:42 -0000 Subject: [GHC] #9594: Cleanup of filepath package In-Reply-To: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> References: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> Message-ID: <060.dc0a459a0a8f2cd2b440e31c35d0cd04@haskell.org> #9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: filepath Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8752 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: upstream => closed * resolution: => fixed Comment: The filepath submodule in GHC HEAD will have all the fixes once Phab:D414 is landed. We need to update it again once a formal release of filepath is made, but closing this here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 18:32:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 18:32:54 -0000 Subject: [GHC] #9575: -XAutoDeriveTypeable fails to generate instances In-Reply-To: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> References: <042.10f2f3cb5a176e03ffba6dac9c337cf9@haskell.org> Message-ID: <057.411b0b2bcd56e374b37aada77e333efc@haskell.org> #9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T8950 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.10.1 => 7.8.4 Comment: > `deriving/should_compile/T8950` already tests for this. > However, at the very least this should be documented (unless it's easy enough to fix) as a known-bug in 7.8.4's manual (should 7.8.4 be ever be released). So this ticket can either be closed, or that documentation should be added. Reverting the milestone back to 7.8.4, since nothing needs to be done for 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 19:48:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 19:48:10 -0000 Subject: [GHC] #9563: Support for deriving Generic1 for data families In-Reply-To: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> References: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> Message-ID: <062.cc24ff25942456843137ba4023868e19@haskell.org> #9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: dreixel Type: bug | Status: merge Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: generics/T9563 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.10.1 => 7.8.4 Comment: I don't know whether this actually needs to go into 7.8.4, but status=merge and milestone=7.10.1 doesn't make sense (there's no 7.10 branch yet, so there's nothing to merge). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 19:56:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 19:56:42 -0000 Subject: [GHC] #9555: internal error: ARR_WORDS object entered! In-Reply-To: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> References: <044.8225d0d1b99d0213ffab974e3a0c55d9@haskell.org> Message-ID: <059.79b0a76e23e748f7d37a4b35a1565f91@haskell.org> #9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (LLVM) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 20:07:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 20:07:10 -0000 Subject: [GHC] #9541: ghc: panic, "RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order" In-Reply-To: <046.68efa89057831cb9c8ddc6a98623ef69@haskell.org> References: <046.68efa89057831cb9c8ddc6a98623ef69@haskell.org> Message-ID: <061.4736a6481b2e26c7174a0d530353bd02@haskell.org> #9541: ghc: panic, "RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order" -------------------------------------+------------------------------------- Reporter: aleator | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 20:34:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 20:34:40 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.01aa5e24b0ba6dacf1c2c40f52348144@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): hrm, I see your point (now that i've caught up on sleep). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 20:52:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 20:52:49 -0000 Subject: [GHC] #9518: Improve error message for unacceptable role annotations In-Reply-To: <047.7d86d581088086ed2263f989759fcf30@haskell.org> References: <047.7d86d581088086ed2263f989759fcf30@haskell.org> Message-ID: <062.dc4d6134ba52d6bcfd2152845bbf8bd6@haskell.org> #9518: Improve error message for unacceptable role annotations -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: infoneeded request | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 20:54:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 20:54:08 -0000 Subject: [GHC] #9563: Support for deriving Generic1 for data families In-Reply-To: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> References: <047.5afce0493774ce2d5de4e9e316ca0dec@haskell.org> Message-ID: <062.ed466a5496b824708555850dc17619b1@haskell.org> #9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: dreixel Type: bug | Status: merge Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: generics/T9563 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Thanks. Merging into 7.8.4 would be good, if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 21:15:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 21:15:53 -0000 Subject: [GHC] #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals In-Reply-To: <046.095a614b9437d6cfe76c234b07042878@haskell.org> References: <046.095a614b9437d6cfe76c234b07042878@haskell.org> Message-ID: <061.13a18142c42ce72f6794fc7295577bb5@haskell.org> #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.2 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: dfeuer, core-libraries-committee@? (added) * owner: => ekmett * component: Compiler => Core Libraries Comment: For reference, from `libraries/base/GHC/Enum.hs`: {{{ #!haskell instance Bounded Word where minBound = 0 -- use unboxed literals for maxBound, because GHC doesn't optimise -- (fromInteger 0xffffffff :: Word). #if WORD_SIZE_IN_BITS == 32 maxBound = W# (int2Word# 0xFFFFFFFF#) #elif WORD_SIZE_IN_BITS == 64 maxBound = W# (int2Word# 0xFFFFFFFFFFFFFFFF#) #else #error Unhandled value for WORD_SIZE_IN_BITS #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 21:20:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 21:20:19 -0000 Subject: [GHC] #9500: Allow GHC defaults to be modified with an environment variable In-Reply-To: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> References: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> Message-ID: <060.f71ba1242470c1c2ac19e2a25ae9d5c9@haskell.org> #9500: Allow GHC defaults to be modified with an environment variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.8.2 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Build System Comment: Someone who understands the build system might be able to tell you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 21:39:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 21:39:43 -0000 Subject: [GHC] #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals In-Reply-To: <046.095a614b9437d6cfe76c234b07042878@haskell.org> References: <046.095a614b9437d6cfe76c234b07042878@haskell.org> Message-ID: <061.5191538d6792c1e3390015aa3e9eafc5@haskell.org> #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.2 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): That's strange... I tried with GHC's going back to 6.12.3 but couldn't reproduce the problem described. I always end up with `GHC.Word.W# (__word 18446744073709551615)` with `-ddump-simpl`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 21:41:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 21:41:09 -0000 Subject: [GHC] #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals In-Reply-To: <046.095a614b9437d6cfe76c234b07042878@haskell.org> References: <046.095a614b9437d6cfe76c234b07042878@haskell.org> Message-ID: <061.6b4d4b20c3c5406bff7278999c673bc9@haskell.org> #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: ekmett Type: task | Status: new Priority: lowest | Milestone: ? Component: Core | Version: 7.8.2 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => lowest * type: bug => task * milestone: => ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 21:45:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 21:45:57 -0000 Subject: [GHC] #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals In-Reply-To: <046.095a614b9437d6cfe76c234b07042878@haskell.org> References: <046.095a614b9437d6cfe76c234b07042878@haskell.org> Message-ID: <061.80e316a1c58513a9f3a60aa525c4ce46@haskell.org> #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: ekmett Type: task | Status: new Priority: lowest | Milestone: ? Component: Core | Version: 7.8.2 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): 6.12.3 was released in June 2010. That code was introduced in {{{ commit 9eef5c0bc0cf1670f55427dacf592c0ea415e7e6 Author: simonmar Date: Tue May 25 09:27:16 2004 +0000 [project @ 2004-05-25 09:27:16 by simonmar] Small performance hack in maxBound::Word. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 22:55:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 22:55:07 -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.dcf0e683c92ec1e836b14bd6a63e0330@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: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 11 23:50:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Nov 2014 23:50:50 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.915c5a10111c20ccb851a92f7e6f0610@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:8 nomeata]: > Maybe it is possible to abstract over the constraints somehow, and write a constraint with value ? in the general case, circumventing any special casing for Coercible? > > (But even if it is possible it includes so much malice that whoever does that waives any right to complain about `map coerce = coerce` :-)) There's a lot I don't understand (including the two comments above), but here's what I think I do understand: 1. Destroying the evidence: If GHC can get its hands on the concrete evidence, it will erase it, because it has the proof it needs. If it can't, it conservatively assumes that the evidence could be `_|_`, because getting this wrong would break the type system. This situation is somewhat unfortunate?if we can ensure the evidence is never bottom, we can be certain never to incur a runtime coercion cost. But without a proof the compiler gurus are unlikely to make that leap, and the people who've spoken up so far are not aware that anyone has proved it. One question in my mind is how this relates to #9701, and also whether GHC ensures that the evidence is as small as possible (coerce itself presumably can be a 0-size token, if it isn't already). 2. Polymorphic `map coerce`, or more generally letting `RULES` get hold of a boxed up `coerce`: The situation here is far less dire. Replacing `map coerce` with `coerce` when coerce is bottom will turn a list of bottoms into bottom. Obviously, that wouldn't be wonderful, but it also wouldn't break the type system. I think that's the sort of thing that would be okay to implement optimistically and wait and see if anything breaks. What's involved in implementing it I wouldn't know. My understanding was that `coerce` is mostly about making things as efficient as possible ''in the face of lots of polymophism'', so just accepting inefficiency because things are too polymorphic doesn't sound right here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 00:19:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 00:19:07 -0000 Subject: [GHC] #9518: Improve error message for unacceptable role annotations In-Reply-To: <047.7d86d581088086ed2263f989759fcf30@haskell.org> References: <047.7d86d581088086ed2263f989759fcf30@haskell.org> Message-ID: <062.1b0f0894f26c9f2a62477b9f1f94a245@haskell.org> #9518: Improve error message for unacceptable role annotations -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: infoneeded request | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): I'm sorry guys, I haven't been haskelling much in the last couple of months. I can't remember how to construct an example, in part because I am still confused by what the rules are, which is why I had trouble interpreting the original error message. To elaborate on what I find confusing about it, I think that it would help if it said *where* `a` was used in a context that required a nominal type role, in the same way that some of the other type error messages do. Annotation says representation but role nominal is required, arising from use of (type constructor) in the type expression (...) at (...) I have a terrible headache or I would research the rules again to figure out how to write a program that produces this error on purpose. I'll attempt it tomorrow if there's time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 01:00:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 01:00:04 -0000 Subject: [GHC] #9781: Make list monad operations fuse In-Reply-To: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> References: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> Message-ID: <060.34fbe03d163110a5ae4cabed108bba1f@haskell.org> #9781: Make list monad operations fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D455 | -------------------------------------+------------------------------------- Comment (by schyler): It would be nice to understand why the `mapM` change did anything at all. That's an enormous difference. I wonder how much real code in the wild has similar properties (is it a lack of INLINEing?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 06:04:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 06:04:27 -0000 Subject: [GHC] #9009: Confusing error message when loading package with TH In-Reply-To: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> References: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> Message-ID: <063.e693f9ecb3de6c84df46e0274476f569@haskell.org> #9009: Confusing error message when loading package with TH -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Package | Version: 7.8.2 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): > Compiling singletons-1.0 with HEAD failes with ... Just remove the `MINIMAL` pragma. > Maybe cabal version (1.20.0.3) is relevant? It looks like my version is identical: {{{ $ cabal --version cabal-install version 1.20.0.3 using version 1.20.0.2 of the Cabal library }}} I see you're using cabal sandbox. Perhaps this is important? I'm using user's package database. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 06:55:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 06:55:22 -0000 Subject: [GHC] #9781: Make list monad operations fuse In-Reply-To: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> References: <045.684de83ae6a55ba91e92d1e56e5c1034@haskell.org> Message-ID: <060.365496a8e19fa757fd5de66e5aacf581@haskell.org> #9781: Make list monad operations fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D455 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 schyler]: > It would be nice to understand why the `mapM` change did anything at all. That's an enormous difference. I wonder how much real code in the wild has similar properties (is it a lack of INLINEing?) I believe it's either a lack of inlining or an unfortunate effect of full laziness. I haven't tried to dig into that particular one so deeply. Short cut fusion is great stuff, but it's on the finicky side; writing library functions so they don't themselves rely on it seems to be a good idea in many cases. The inliner will be less likely to over-estimate their cost, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 07:26:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 07:26:24 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.c26a7fdba1c969b5f25e5c5e9b962a7a@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): It would be great if we could have a test for this so we're sure this does not regress again. I looked at the repo and the code to reproduce this is pretty big. I wonder if it could be reduced further to include it in the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 08:51:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 08:51:29 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.9aea8c17267b28ccd8bdb810fd304fca@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > I think that's the sort of thing that would be okay to implement optimistically and wait and see if anything breaks I wasn?t saying that we shouldn?t; I was just explaining why it is not. I think one solution would be to assume everying is strict in values of type `Coercible`, so that the optimizer will move the `case` out as far as possible, outside the call to map, thus allowing the rule to match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 09:51:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 09:51:24 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.33ab2d0cd2c013ef3e2488f155e866ab@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Simon, I have code in production where the contract for a newtype and the wrapper you want to have enforced here doesn't hold -- in particular cases where the newtype _solely exists_ to create a Storable with different alignment and sizing properties. This comes up for all sorts of things, packed colors, bit arrays, etc, structures folks are marshaling for std140 compliance to/from OpenGL uniform buffers... It seems dangerous to me to tie a contract about the behavior of a user defineable class to representability. If we're letting users define Storable instances is seems strange to me to conflate the two notions of representation (bit representation of Storable) and the heap representation for GHC. This puts me very much in the Plan A camp, personally. Plan B it seems could just lead to segfaults for existing user instances out there. With Ptr we're basically handing the user a live grenade, they know handling it wrong can lead to segfaults, and they do so with due care. With an Array I don't think there is any such expectation of unsafety, and folks are expecting things to 'just work'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 09:58:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 09:58:37 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.531ffdbd4a7990b0b931ca3a13ffd3c7@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I'll take that as a casting vote in favour of Plan A. Richard: would you like to execute on that (including the Note to explain)? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 10:04:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 10:04:57 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.5384ccfbf7be126d8effbe9d592ca017@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a" Implement new integer-gmp2 from scratch (re #9281) This is done as a separate `integer-gmp2` backend library because it turned out to become a complete rewrite from scratch. Due to the different (over)allocation scheme and potentially different accounting (via the new `{shrink,resize}MutableByteArray#` primitives), some of the nofib benchmarks actually results in increased allocation numbers (but not necessarily an increase in runtime!). I believe the allocation numbers could improve if `{resize,shrink}MutableByteArray#` could be optimised to reallocate in-place more efficiently. Here are the more apparent changes in the latest nofib comparision between `integer-gmp` and `integer-gmp2`: ------------------------------------------------------------------ Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------ ... bernouilli +1.6% +15.3% 0.132 0.132 0.0% ... cryptarithm1 -2.2% 0.0% -9.7% -9.7% 0.0% ... fasta -0.7% -0.0% +10.9% +10.9% 0.0% ... kahan +0.6% +38.9% 0.169 0.169 0.0% ... lcss -0.7% -0.0% -6.4% -6.4% 0.0% ... mandel +1.6% +33.6% 0.049 0.049 0.0% ... pidigits +0.8% +8.5% +3.9% +3.9% 0.0% power +1.4% -23.8% -18.6% -18.6% -16.7% ... primetest +1.3% +50.1% 0.085 0.085 0.0% ... rsa +1.6% +53.4% 0.026 0.026 0.0% ... scs +1.2% +6.6% +6.5% +6.6% +14.3% ... symalg +1.0% +9.5% 0.010 0.010 0.0% ... transform -0.6% -0.0% -5.9% -5.9% 0.0% ... ------------------------------------------------------------------ Min -2.3% -23.8% -18.6% -18.6% -16.7% Max +1.6% +53.4% +10.9% +10.9% +14.3% Geometric Mean -0.3% +1.9% -0.8% -0.8% +0.0% (see P35 / https://phabricator.haskell.org/P35 for full report) By default, `INTEGER_LIBRARY=integer-gmp2` is active now, which results in the package `integer-gmp-1.0.0.0` being registered in the package db. The previous `integer-gmp-0.5.1.0` can be restored by setting `INTEGER_LIBRARY=integer-gmp` (but will probably be removed altogether for GHC 7.12). In-tree GMP support has been stolen from the old `integer-gmp` (while unpatching the custom memory-allocators, as well as forcing `-fPIC`) A minor hack to `ghc-cabal` was necessary in order to support two different `integer-gmp` packages (in different folders) with the same package key. There will be a couple of follow-up commits re-implementing some features that were dropped to keep D82 minimal, as well as further clean-ups/improvements. More information can be found via #9281 and https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2 Reviewed By: austin, rwbarton, simonmar Differential Revision: https://phabricator.haskell.org/D82 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 10:07:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 10:07:13 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.e300ac27e24c20b535ecae2160ffd9a4@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): (Wrote the bulk of this before you replied, figured I'd send it anyways) Hrmm, actually one could argue a stronger statement, it seems to me that Plan B is inconsistent. How would you even construct a type for, say, endian swapping, or going to/from network order for a Word32 upon storage, you'd still want the underlying type to be a newtype, rather than just randomly throw in a bottom with an unnecessary 'data' for no reason, and I've seen both of these as instances in the wild as part of larger Storable types. Also merely having sizeOf agree isn't sufficient to ensure correctness. Consider the above case of order swapping on storage, sizeOf gives the same answer in the above case, and if you coerced a boxed array nothing changes, but if you coerced an unboxed array you'd get all the characters spontaneously byte reversing due to effectively going through a "reinterpret_cast<>". It strikes me that two very different things would be happening semantically there, so having UArray have a nominal element type, even though Array is able to (and should be) representational makes sense to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 10:22:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 10:22:52 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.09fbb1697b1545af6c8ba99be6f2bc8c@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): OK good. So '''are''' boxed arrays representational? They certainly should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 10:44:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 10:44:05 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.729ecacbf20c6a2199636c60d372d9b9@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Boxed arrays are representational (just by the default roles) though both `Array` and `UArray` are currently ''also'' `representational` in the first argument. =/ That is dangerous for much the same reason as relying on the semantics of `Storable` not changing to a newtype, it is often the very point that the newtype would change such an instance. In fact `UArray` is currently even worse and gets inferred as {{{ type role UArray representational phantom -- ack! }}} because the underlying constructor doesn't mention the element type at all. We basically just ignored roles in the `array` package when shipping 7.8.x -- It strikes me that we should have {{{ type role Array nominal representational type role UArray nominal nominal }}} The first argument is formed nominal by depending upon the chosen `Ix` instance, and in the case of `UArray` the second argument is forced nominal by depending upon the chosen `Storable` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 11:07:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 11:07:17 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.1964d7e44c4455dfbd460e03334526ff@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Tracking stack depths: this will go away when Richard completes his work of treating Coercible constraints more like nominal-equality constraints. However, a value of type `Coercible a b` can certainly be bottom in Core, even if type inference engine will never produce it. More promising is just to make functions strict in `Coercible` arguments. I should look again at `-fdicts-strict`. Meanwhile Richard is also thinking about the whole lifted/unlifted equality thing, and I'd like to see how the dust settles there. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 12:14:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 12:14:12 -0000 Subject: [GHC] #9794: Additional assert function: assert :: Bool -> String -> a -> a Message-ID: <047.b9adfcb4efe9a32bd4510ad18b924c8c@haskell.org> #9794: Additional assert function: assert :: Bool -> String -> a -> a -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, we have an assert function in GHC.Base: {{{#!hs -- Assertion function. This simply ignores its boolean argument. -- The compiler may rewrite it to @('assertError' line)@. -- | If the first argument evaluates to 'True', then the result is the -- second argument. Otherwise an 'AssertionFailed' exception is raised, -- containing a 'String' with the source file and line number of the -- call to 'assert'. -- -- Assertions can normally be turned on or off with a compiler flag -- (for GHC, assertions are normally on unless optimisation is turned on -- with @-O@ or the @-fignore-asserts@ -- option is given). When assertions are turned off, the first -- argument to 'assert' is ignored, and the second argument is -- returned as the result. -- SLPJ: in 5.04 etc 'assert' is in GHC.Prim, -- but from Template Haskell onwards it's simply -- defined here in Base.lhs assert :: Bool -> a -> a assert _pred r = r }}} This get's rewritten by the type checker to assertError: {{{#!hs Note [Adding the implicit parameter to 'assert'] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The typechecker transforms (assert e1 e2) to (assertError "Foo.hs:27" e1 e2). This isn't really the Right Thing because there's no way to "undo" if you want to see the original source code in the typechecker output. We'll have fix this in due course, when we care more about being able to reconstruct the exact original program. }}} I would like to propose an additional one: {{{#!hs assertStr :: Bool -> String -> a -> a assertStr _pred msg r = r }}} NOTE: what is a name that is more consistent with the code base? That would get rewritten as: {{{#!hs assertError ("Foo.hs:27 - " ++ show msg) e1 e2 }}} Why? This makes assertions a bit more meaningful when reading the error message, and they can replace the existing ASSERT2 macros throughout the code base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 12:27:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 12:27:13 -0000 Subject: [GHC] #9784: Improve error message for misplaced quote inside promoted qualified type In-Reply-To: <047.546c05d155a967089478b2cd78e20337@haskell.org> References: <047.546c05d155a967089478b2cd78e20337@haskell.org> Message-ID: <062.4ed06c4c01d9e4214d5188dd324e7e9c@haskell.org> #9784: Improve error message for misplaced quote inside promoted qualified type -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3155 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Good idea, but not so clear how to implement it. Your text tokenises as {{{ bar :: Rpoxy Foo . 'Z -> Int }}} and the parse error happens on the "." before the parse has even seen the `'Z`. I suppose the lexer could see `Foo.'Z` and warn that it looks suspicious. Or even lex it as if you had written `'Foo.Z`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 12:33:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 12:33:41 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.b061398c98ba53b0d3110a74608baeb3@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not sure whether you want to dump out the entire source code (after expanding splices); or just the splices (which is what `-ddump-splices` does. If the former, then you need to dump the typechecker output (rather than the earlier renamer output) because type splices are expanded by the type checker. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 12:31:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 12:31:05 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.555f14cf0b2b1f39123ceb86524d1777@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: GregWeber Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8624 Test Case: | Blocking: | Differential Revisions: Phab:D460 | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 7.10.1 Comment: Let's do this for 7.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 12:34:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 12:34:24 -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.28b2348c42bdcd45e4de494328aa686e@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm ok with `-fwarn-unticked-promoted-constructors` if someone wants to add (and document) it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 12:38:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 12:38:13 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.fc8ca95e12b956c075f67dc14ebd666a@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the solution is not to be very delicate about how to place the semicolons for the do-notation. Rather, we should just use braces and semicolons for let-notation too. At least for lets in do-notation but perhaps for all. Then you'd get {{{ bar arg0 arg1 arg2 arg3 arg4 arg5 arg6 arg7 arg8 arg9 = do {let { x = 5 }; return x} }}} which should work fine. Anyone want to do this? It would be consistent with the story for do- notation. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 13:03:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 13:03:37 -0000 Subject: [GHC] #9795: Debug.Trace.trace is too strict Message-ID: <049.4be06b064bc5b595e6d6c5ec99f21602@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider the following toy example: {{{#!hs import Debug.Trace f n = let res = g n in (trace $ unlines ["in: " ++ show n, "out: " ++ show res]) res where g n = if n <= 1000 then n+1 else g n main = print $ [f 500, f 302, f 2000, f 22] }}} When run it outputs: {{{ in: 500 out: 501 in: 302 out: 303 ^C }}} In a real example, for a program that hangs, where one only ''suspects'' that `f` may be the culprit, and where `f` is being called from various places with different values, this output is not very useful (and in fact, it is misleading). My mental model of the `trace` function is something along these lines: {{{#!hs myTrace :: String -> a -> a myTrace s a = unsafePerformIO $ do putStrLn s return a }}} and in fact, replacing `trace` by `myTrace` in the example above one gets the more useful: {{{ in: 500 out: 501 in: 302 out: 303 in: 2000 ^C }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 14:18:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 14:18:23 -0000 Subject: [GHC] #9784: Improve error message for misplaced quote inside promoted qualified type In-Reply-To: <047.546c05d155a967089478b2cd78e20337@haskell.org> References: <047.546c05d155a967089478b2cd78e20337@haskell.org> Message-ID: <062.2626534e97b7abf929a7d24535951f79@haskell.org> #9784: Improve error message for misplaced quote inside promoted qualified type -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3155 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): Yes, I think the lexer makes more sense. Although it doesn't quite make sense to me, presumably there's a good reason for making `'Foo.Z` the right thing. If that's the case, then I think I'd rather see a lexer warning that have it lex correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 15:15:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 15:15:48 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.0eaa638cbaaae5c4da7c67700960da7c@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Apologies for being obtuse about this, but I can't proceed until I have a ''very'' concrete statement of what wants to be done here. Which types -- the full list -- should have what roles? And, I can attempt to write a Note, but I'm worried about getting the details wrong, and will want a double-check. I will post it here before pushing. So, I'll stand by waiting for more direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 15:36:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 15:36:08 -0000 Subject: [GHC] #9794: Additional assert function: assert :: Bool -> String -> a -> a In-Reply-To: <047.b9adfcb4efe9a32bd4510ad18b924c8c@haskell.org> References: <047.b9adfcb4efe9a32bd4510ad18b924c8c@haskell.org> Message-ID: <062.efbfee24d12a4556b4852e019157300b@haskell.org> #9794: Additional assert function: assert :: Bool -> String -> a -> a -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): The difficulty here is that these functions are not ''abstractable''. For example, in GHC we'd want a function {{{ assertGHC :: Bool -> SDoc -> a -> a }}} where the second argument is an `SDoc` not a string. We could define it in a library module, in terms your `assertStr`, thue: {{{ assertGHC b doc x = assertStr b (showSDoc doc) x }}} but now the location reported would be in the library module. How to make this abstractable? See #9049, esp [wiki:ExplicitCallStack/ImplicitLocations] I'm reluctant make the present thing a tiny bit better; I'd rather do something more thorough. I'd be happy if someone made progress on #9049. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 15:36:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 15:36:35 -0000 Subject: [GHC] #9792: map/coerce rule never seems to fire In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.c899a0df7591dd6f8179c18c15c705de@haskell.org> #9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Forcing dictionary arguments to be strict helps here, but would that always work? For example, if we have {{{ foo :: forall (c :: Constraint). c => Proxy c -> () }}} would that still be inferred to be strict in its first (Core) parameter? Separately, I don't think my lifted/unlifted thoughts will have impact here, although the rewrite of the `Coercible` solver may. That task will begin shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 17:18:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 17:18:27 -0000 Subject: [GHC] #9796: Implement amap/coerce rule for `Array` Message-ID: <045.6e18c11ce0de8ebcd631eb7d710d6e30@haskell.org> #9796: Implement amap/coerce rule for `Array` -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We have `map/coerce`; there's no reason not to have `amap/coerce` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 17:24:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 17:24:25 -0000 Subject: [GHC] #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types Message-ID: <045.54c1b52407bd07f539504f3c758ce78d@haskell.org> #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we see `m >>= (\_ -> n)` with a type that admits an optimized `>>` or `<$`, we should try to take advantage of that. I don't currently know if this applies to any types under "GHC HQ" control. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 17:32:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 17:32:39 -0000 Subject: [GHC] #9496: Simplify primitives for short cut fusion In-Reply-To: <045.ac67b2e89db14da0e2a7c577a8db7e03@haskell.org> References: <045.ac67b2e89db14da0e2a7c577a8db7e03@haskell.org> Message-ID: <060.1797bc5881b7903e5b1f35838c77210e@haskell.org> #9496: Simplify primitives for short cut fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: lowest | Milestone: ? Component: Core | Version: 7.8.3 Libraries | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * priority: normal => lowest * milestone: => ? Comment: Duncan Coutts doesn't seem to think this is really a problem, per se. It even has an advantage: we avoid speculative rewrites that can be bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 18:03:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 18:03:47 -0000 Subject: [GHC] #9009: Confusing error message when loading package with TH In-Reply-To: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> References: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> Message-ID: <063.565beb3debdf9ce03659674ed6483957@haskell.org> #9009: Confusing error message when loading package with TH -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Package | Version: 7.8.2 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This is still not reproducable for me with 7.8.3 (I get the same error from comment:3). I am using the haskell-platform 2014.02 in the global database, an initially empty user database (deleted ~/.ghc and ~/.cabal) and no sandbox. But it I did reproduce it with a recent HEAD. I followed the steps from comment:2 and also removed the `MINIMAL` pragma from src/Data/Singletons/Prelude/Ord.hs in `singletons-1.0`. {{{ $ uname -a Linux feng-laptop 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ /opt/ghc/head/bin/ghc-pkg list /opt/ghc/head/lib/ghc-7.9.20141108/package.conf.d Cabal-1.21.1.0 array-0.5.0.1 base-4.8.0.0 bin-package-db-0.0.0.0 binary-0.7.1.0 bytestring-0.10.4.0 containers-0.5.5.1 deepseq-1.3.0.3 directory-1.2.1.1 filepath-1.3.0.3 ghc-7.9.20141108 ghc-prim-0.3.1.0 haskeline-0.7.1.3 haskell2010-1.1.2.1 haskell98-2.0.0.4 hoopl-3.10.0.2 hpc-0.6.0.2 integer-gmp-0.5.1.0 old-locale-1.0.0.7 old-time-1.1.0.3 pretty-1.1.1.1 process-1.2.0.1 rts-1.0 template-haskell-2.10.0.0 terminfo-0.4.0.0 time-1.5 transformers-0.4.1.0 unix-2.7.0.2 xhtml-3000.2.1 /home/thomas/.ghc/x86_64-linux-7.9.20141108/package.conf.d mtl-2.2.1 singletons-1.0 syb-0.4.2 th-desugar-1.4.2 $ /opt/ghc/head/bin/ghc-7.9.20141108 Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) : can't load .so/.DLL for: /home/thomas/.cabal/lib/x86_64 -linux- ghc-7.9.20141108/singletons-1.0/libHSsingl_LteS7xqJUFW9l0IV1AW3w0-ghc7.9.20141108.so (/home/thomas/.cabal/lib/x86_64-linux- ghc-7.9.20141108/singletons-1.0/libHSsingl_LteS7xqJUFW9l0IV1AW3w0-ghc7.9.20141108.so: undefined symbol: singlzuLteS7xqJUFW9l0IV1AW3w0_DataziSingletonsziSingleziMonad_wrapUnSingFun5_closure) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.8176dd95692d7c12af39883cae175433@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D424 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d782694f47c3b05605e4564850623dbd03af7ecc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d782694f47c3b05605e4564850623dbd03af7ecc" Fix #9066. When splicing in a fixity declaration, look for both term-level things and type-level things. This requires some changes elsewhere in the code to allow for more flexibility when looking up Exact names, which can be assigned the wrong namespace during fixity declaration conversion. See the ticket for more info. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:04 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.46109fb94e3590724df92f10b06c8f71@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D424 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1d35c85679416a955a4aee8e8a6a1b71d4ac827e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1d35c85679416a955a4aee8e8a6a1b71d4ac827e" Test #9066 in th/T9066 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.66173e553537c25577a7f2ff26f9a1cf@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D439 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"767feb370d0a05a78a34a9498fe11b90d395d158/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="767feb370d0a05a78a34a9498fe11b90d395d158" Test #8100 in th/T8100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.f636eefb3f4988acd5b476eb3be90482@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: 9526 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D437 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"88a42be1b40c55241f835da815faa9eb8b356331/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="88a42be1b40c55241f835da815faa9eb8b356331" Derive Generic for TH types (#9527) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.66ae1624443c85b1f1504bf9dfa1fe59@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: 9526 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D437 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1d66167e56317bbd0e06301fe3cbdc40c9c3e34b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1d66167e56317bbd0e06301fe3cbdc40c9c3e34b" Remove unboxed Int# fields from NameFlavour (#9527) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -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.282035563f86e50d676385884138c052@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D458 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"90a2bb6fc66e9341ae466ff3ff6c9da438e159c2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="90a2bb6fc66e9341ae466ff3ff6c9da438e159c2" Testsuite wibbles due to #9204 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.53d8c1c98cfa971b8355e10643903847@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D439 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"4ac9e902327683ba032df5fb0e92a80c7b7fccd4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4ac9e902327683ba032df5fb0e92a80c7b7fccd4" Fix #8100, by adding StandaloneDerivD to TH's Dec type. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.a2c9ede07b03028ffb9ff7120115d9ee@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D469 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e6e45a1c497eae37fbc5daf5e201fe97181e840c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e6e45a1c497eae37fbc5daf5e201fe97181e840c" Test #9404 (typecheck/should_compile/T9404 and T9404b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #9064: Support default class method signatures in Template Haskell In-Reply-To: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> References: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> Message-ID: <062.ea858547cefd4e05ebbf7aa5586e1686@haskell.org> #9064: Support default class method signatures in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D440 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e4efb7b8de8ff3781a42e69e35dee981d9885fcf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e4efb7b8de8ff3781a42e69e35dee981d9885fcf" Fix #9064 by adding support for generic default signatures to TH. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -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.1fdcbf97329b22468f8bf3be20d3df95@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D458 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"ee0f34d53291a7223185f83c644a25b54ea16fab/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ee0f34d53291a7223185f83c644a25b54ea16fab" Fix #9204 by outputting extra info on boot file mismatch. [skip ci] -- testsuite wibbles are in next commit }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -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.0d083d0ee06cb2563d05a20ae0a8c4df@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D458 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"ec8781f063d246a79ce1d4eb207dbee4b6317c94/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ec8781f063d246a79ce1d4eb207dbee4b6317c94" Test #9204 in roles/should_fail/T9204 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #9788: `coerce` has an impossible type In-Reply-To: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> References: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> Message-ID: <062.594d9996dff846fb8a68e4bf8a17c0bd@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D468 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"294ac47ef7aa68d09cf730c60223259893fc0933/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="294ac47ef7aa68d09cf730c60223259893fc0933" Fix #9788 by giving `coerce` the right type. No test case added, as the original mistake is just one level up from a typo. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.020f0e4c9f1ed828bba4bfa84f512773@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D469 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"fe6a51715a23e2ee31e1d03b71f06c4417e964e0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fe6a51715a23e2ee31e1d03b71f06c4417e964e0" Testsuite wibble due to #9404 [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #9064: Support default class method signatures in Template Haskell In-Reply-To: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> References: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> Message-ID: <062.f1bf9e4f66df98ed32ef9d797c074e3d@haskell.org> #9064: Support default class method signatures in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D440 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"fe71a7e6e3513ff18f7e6ec57284168c052262fc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fe71a7e6e3513ff18f7e6ec57284168c052262fc" Test #9064 in th/T9064 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:52:05 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.f03e1ebfda935b66a0eda9795efd1f1b@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D469 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1e2002d8e89e3267e2c9c8d92235ee083a272657/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1e2002d8e89e3267e2c9c8d92235ee083a272657" Fix #9404 by removing tcInfExpr. See the ticket for more info about the new algorithm. This is a small simplification, unifying the treatment of type checking in a few similar situations. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:53:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:53:21 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.9f3467edff67e412c3ab5d65ab0bee5e@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T9066 | Blocking: | Differential Revisions: Phab:D424 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * testcase: => th/T9066 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:56:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:56:07 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.fb76a6505294674db5eb71a2c3c797ef@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D437 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * resolution: => fixed * blockedby: 9526 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:57:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:57:11 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.0c86786245f6bf3df3ce28278fedd826@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: goldfire Type: feature | Status: closed request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: th/T8100 | Blocking: | Differential Revisions: Phab:D439 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * testcase: => th/T8100 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:57:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:57:56 -0000 Subject: [GHC] #9064: Support default class method signatures in Template Haskell In-Reply-To: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> References: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> Message-ID: <062.4e763ef58441170d777fb20ba78fc3b8@haskell.org> #9064: Support default class method signatures in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: th/T9064 | Blocking: | Differential Revisions: Phab:D440 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * testcase: => th/T9064 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 19:59:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 19:59:00 -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.16834a875eb1fc57f6639db303fd151a@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.2 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | roles/should_fail/T9204 | Blocking: | Differential Revisions: Phab:D458 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * testcase: => roles/should_fail/T9204 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 20:00:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 20:00:02 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.a1d0c9de300b8f7ccc6a3a72a5c4cb9c@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D469 | -------------------------------------+------------------------------------- Comment (by goldfire): Keeping ticket open. I merged my solution at Simon's request, but there's still an outstanding refactoring task. See Phab:D469. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 20:00:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 20:00:41 -0000 Subject: [GHC] #9788: `coerce` has an impossible type In-Reply-To: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> References: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> Message-ID: <062.5e03cdee95da531b3214363d84409dfa@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D468 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 20:02:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 20:02:51 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.8f3f65a06814ddc84507c2cae22fdc74@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Confirmed that the original program is accepted in HEAD. Adding a test case soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 20:46:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 20:46:24 -0000 Subject: [GHC] #9796: Implement amap/coerce rule for `Array` In-Reply-To: <045.6e18c11ce0de8ebcd631eb7d710d6e30@haskell.org> References: <045.6e18c11ce0de8ebcd631eb7d710d6e30@haskell.org> Message-ID: <060.114c5dcbbeee9d5a8acd1d7bb58a4dd0@haskell.org> #9796: Implement amap/coerce rule for `Array` -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D471 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D471 Comment: Doing this required me to delay inlining `amap` until phase 1, which required me to rewrite it to avoid relying on list fusion. This has a nice side benefit: the compiled code ends up smaller because it avoids a redundant test relating to `enumFromTo` and redundant array freezing code that went with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 20:48:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 20:48:41 -0000 Subject: [GHC] #9792: map/coerce rule does not fire until the coercion is known (was: map/coerce rule never seems to fire) In-Reply-To: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> References: <045.97beacabcb45f921d26944c1e1e46508@haskell.org> Message-ID: <060.9711b5c092140d6df811928d00dd9851@haskell.org> #9792: map/coerce rule does not fire until the coercion is known -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 21:47:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 21:47:16 -0000 Subject: [GHC] #9794: Additional assert function: assert :: Bool -> String -> a -> a In-Reply-To: <047.b9adfcb4efe9a32bd4510ad18b924c8c@haskell.org> References: <047.b9adfcb4efe9a32bd4510ad18b924c8c@haskell.org> Message-ID: <062.80bf7814197aa13e5ecdb9e01064cd40@haskell.org> #9794: Additional assert function: assert :: Bool -> String -> a -> a -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: duplicate | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rodlogic): * status: new => closed * resolution: => duplicate Comment: Replying to [comment:1 simonpj]: > The difficulty here is that these functions are not ''abstractable''. For example, in GHC we'd want a function > {{{ > assertGHC :: Bool -> SDoc -> a -> a > }}} > where the second argument is an `SDoc` not a string. We could define it in a library module, in terms your `assertStr`, thue: > {{{ > assertGHC b doc x = assertStr b (showSDoc doc) x > }}} > but now the location reported would be in the library module. > > How to make this abstractable? See #9049, esp [wiki:ExplicitCallStack/ImplicitLocations] > > I'm reluctant make the present thing a tiny bit better; I'd rather do something more thorough. I'd be happy if someone made progress on #9049. > > Simon I now understand the basic problem and what you mean by 'abstractable': we can't just change the existing {{{GHC.Base.assert}}} function to include a message parameter and create a wrapper function to keep it backwards compatible. And introducing a new assertStr would require a second hard- coded wiring into the compiler to make it just like assert. I am new to GHC, but would be willing to give it a shot if you can give me a few pointers. For now, I will close this ticket as a duplicate of #9049 to keep things centralized and add a reference back here. Moving to #9049 ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 21:48:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 21:48:23 -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.30325957fd3cc726bcf1acfdf5e8ab84@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): Closed #9794 as a duplicate of this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 22:07:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 22:07:50 -0000 Subject: [GHC] #9608: Type level as-patterns In-Reply-To: <046.b5996effd54422c4b764b9e3de90a562@haskell.org> References: <046.b5996effd54422c4b764b9e3de90a562@haskell.org> Message-ID: <061.23531367f6e8c19d961240f6a935d44e@haskell.org> #9608: Type level as-patterns -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: duplicate | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Duplicate of #8109. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 22:08:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 22:08:21 -0000 Subject: [GHC] #8109: Type family patterns should support as-patterns. In-Reply-To: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> References: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> Message-ID: <065.474600e4cfb99bdd6401f146142aca1a@haskell.org> #8109: Type family patterns should support as-patterns. -------------------------------------+------------------------------------- Reporter: | Owner: carlhowells | Status: new Type: feature | Milestone: request | Version: 7.6.3 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): See also example at #9608, which is a duplicate of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 22:14:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 22:14:25 -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.f18299e2315549d34631021568f9ea73@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): I read the wiki:ExplicitCallStack/ImplicitLocations, and the general approach makes sense. The notion of a stack of source locations startes to loose me, though. Could you give a more explicit example? Does it basically mean that {{{show (?location :: Location)}}} below will render g's location and g's caller location? Or am I misunderstanding this? {{{ h :: [a] -> Int h as = f as g :: (?location :: Location) => [a] -> Int g as = f as f :: (?location :: Location) => [a] -> Int f [] = error ("Failure at " ++ show (?location :: Location)) f (x:xs) = ... }}} Could you point me to: 1. In what module should Location be created? 2. Where in the type checker should a Location be created? 3. Where should Locations be pushed? I can then take a closer look and come back with additional questions. @nh2 I am not sure how far along you are with this, so ping me if this is basically done already ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 22:27:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 22:27:46 -0000 Subject: [GHC] #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types In-Reply-To: <045.54c1b52407bd07f539504f3c758ce78d@haskell.org> References: <045.54c1b52407bd07f539504f3c758ce78d@haskell.org> Message-ID: <060.518ee3e9e3a6a39818081892aab651a3@haskell.org> #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): The danger with this proposal of course occurs when users have {{{ m >> n = m >>= \_ -> n }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 22:30:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 22:30:17 -0000 Subject: [GHC] #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types In-Reply-To: <045.54c1b52407bd07f539504f3c758ce78d@haskell.org> References: <045.54c1b52407bd07f539504f3c758ce78d@haskell.org> Message-ID: <060.3dcd65d54fad352b8b193a1ac4996af0@haskell.org> #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 ekmett]: > The danger with this proposal of course occurs when users have > > {{{ > m >> n = m >>= \_ -> n > }}} There is no danger, because the rules would only apply to specified types. The main question is how likely it is that we'll be able to work around inlining in various situations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 23:05:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 23:05:48 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.431e852238da278806a82a28718dc383@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by roldugin): There was a discussion in the mailing list and I fixed it based on advice I got there. The fix worked for me but I haven't validated it. I no longer have write access to the repo, so I've attached it above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 23:26:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 23:26:47 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.70c21b43ebb636c309f9b5998cd23f65@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Did you test your fix? {{{ let {x = 3} ; {y = 4} in x+y }}} is not valid Haskell, but is (I believe) what your patch will generate. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 23:38:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 23:38:03 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.1191d86c39cba133f760a2e44cbeaff6@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.6.3 Component: Compiler | Keywords: Debian (FFI) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Kritzefitz: thank you for the report. I am adding an example here for later reference. Please let me me know if there are any mistakes in the text below, I just learned this stuff tonight. On Ubuntu 14.04, `libbsd.so` (unversioned) is a symbolic link to the file `libbsd.so.0.6.0` (versioned). That symbolic link is created by the `libbsd-dev` (dev) package, while the library file is installed by the `libbsd0` (runtime) package. {{{ $ ll /usr/lib/x86_64-linux-gnu/libbsd.so lrwxrwxrwx 1 root root 37 Mar 20 2014 /usr/lib/x86_64-linux-gnu/libbsd.so -> /lib/x86_64-linux-gnu/libbsd.so.0.6.0 $ dpkg -S /usr/lib/x86_64-linux-gnu/libbsd.so libbsd-dev: /usr/lib/x86_64-linux-gnu/libbsd.so $ dpkg -S /lib/x86_64-linux-gnu/libbsd.so.0.6.0 libbsd0:amd64: /lib/x86_64-linux-gnu/libbsd.so.0.6.0 }}} This is a small program (called `testbsd.hs`) that calls a function in the libbsd library via the foreign function interface: {{{#!haskell module Main where import Foreign.C.Types foreign import ccall "arc4random" version :: CUInt main = print version }}} GHC links this program to `libbsd.so.0`, not `libbsd.so.0.6.0`, so the dev package will be needed to run it: {{{ $ ghc --make -lbsd testbsd.hs [1 of 1] Compiling Main ( testbsd.hs, testbsd.o ) Linking testbsd ... $ ldd testbsd ... libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007faef5c2c000) ... $ ./testbsd 1131902945 }}} Note that some runtime packages do create the link from the unversioned to the versioned library themselves. This seems to be in particular true for all libraries in the `/lib/` directory. For example for `libpng`: {{{ $ ll /lib/x86_64-linux-gnu/libpng12.so.0 lrwxrwxrwx 1 root root 18 Apr 1 2014 /lib/x86_64-linux-gnu/libpng12.so.0 -> libpng12.so.0.50.0 $ dpkg -S /lib/x86_64-linux-gnu/libpng12.so.0.50.0 libpng12-0:amd64: /lib/x86_64-linux-gnu/libpng12.so.0.50.0 $ dpkg -S /lib/x86_64-linux-gnu/libpng12.so.0 libpng12-0:amd64: /lib/x86_64-linux-gnu/libpng12.so.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 12 23:50:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Nov 2014 23:50:30 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.ca58a3db2c37b466985176170233eab9@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by roldugin): You're right! `let` expressions should be fine: {{{ > pprint <$> runQ [| let { x = 3; y = 4 } in x + y |] "let {x_0 = 3; y_1 = 4}\n in x_0 GHC.Num.+ y_1" }}} But there is indeed a problem with `let` statements: {{{ > pprint <$> runQ [| do let { x = 3; y = 4 } ; return (x + y) |] "do {let {x_0 = 3}; {y_1 = 4}; GHC.Base.return (x_0 GHC.Num.+ y_1)}" }}} I think pretty printing `LetS` will need to use custom `pprDecs` like `LetE` does around line 149. Unfortunately, I can't do it right now but I will when I get a minute. George -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 00:12:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 00:12:09 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.35ca8e55e676c364227d85b1c2ae30c1@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.6.3 Component: Compiler | Keywords: Debian (FFI) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Kritzefitz: thank you once again for the report. My first version of the above text was wrong. This is the corrected version. I don't understand the problem you're proposal is trying to solve. Could you please give an example of the situation on your system? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 00:25:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 00:25:38 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.54979a1f0274e5e559ed3ac17c66a3b4@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D442 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D442 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 00:30:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 00:30:47 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib In-Reply-To: <047.c599b15a57b1de1c882b98999535443e@haskell.org> References: <047.c599b15a57b1de1c882b98999535443e@haskell.org> Message-ID: <062.3b8999b70cf6db4a125873ce485ee147@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: aseipp Type: bug | Status: infoneeded Priority: high | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Did this indeed turn out to be a bug in `zlib`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 01:16:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 01:16:06 -0000 Subject: [GHC] #9453: The example for GHC Generics is kinda broken In-Reply-To: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> References: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> Message-ID: <063.c133f14c4b5a59db77f1b9cb0ad8eabb@haskell.org> #9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Documentation bug * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 01:34:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 01:34:21 -0000 Subject: [GHC] #9442: Building GHC with Clang In-Reply-To: <047.60025353427d2f2c7d3fc692e6f27863@haskell.org> References: <047.60025353427d2f2c7d3fc692e6f27863@haskell.org> Message-ID: <062.8a397b164f48758b0d31e593282cd3c6@haskell.org> #9442: Building GHC with Clang -------------------------------------+------------------------------------- Reporter: conradwt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * os: Unknown/Multiple => MacOS X * component: Compiler => Build System * resolution: => worksforme Comment: The instructions for building GHC with Clang on OSX can be found on the wiki: [wiki:Building/Preparation/MacOSX]. conradwt: please reopen this ticket if you're still having difficulties. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 01:41:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 01:41:46 -0000 Subject: [GHC] #9438: panic: loading archives not supported In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.36c35098794c9cee416533fb38d09795@haskell.org> #9438: panic: loading archives not supported -----------------------------------+---------------------------------- Reporter: egl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8164 Differential Revisions: | -----------------------------------+---------------------------------- Changes (by thomie): * cc: carter (added) * related: => #8164 Comment: I am CC-ing carter, since he opened and closed #8164, which looks similar, and maybe knows what's going on. egl: how does one install `atlas`? Please provide instructions so this bug can be more easily reproduced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 01:50:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 01:50:05 -0000 Subject: [GHC] #9432: IncoherentInstances are too restricted In-Reply-To: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> References: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> Message-ID: <061.f5b7919a4075ed8e481e5eb893e3d083@haskell.org> #9432: IncoherentInstances are too restricted -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8141 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8141 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 02:00:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 02:00:24 -0000 Subject: [GHC] #9431: integer-gmp small Integer multiplication does two multiplications on x86 In-Reply-To: <047.affdf8ab1c2013e525e334d331ebc594@haskell.org> References: <047.affdf8ab1c2013e525e334d331ebc594@haskell.org> Message-ID: <062.496faaf877c585d65414c00220c44739@haskell.org> #9431: integer-gmp small Integer multiplication does two multiplications on x86 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (NCG) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * failure: None/Unknown => Runtime performance bug * component: Compiler => Compiler (NCG) Comment: For reference, from `libraries/integer-gmp2/src/GHC/Integer/Type.hs`: {{{#!haskell -- | Multiply two 'Integer's timesInteger :: Integer -> Integer -> Integer timesInteger _ (S# 0#) = S# 0# timesInteger (S# 0#) _ = S# 0# timesInteger x (S# 1#) = x timesInteger (S# 1#) y = y timesInteger x (S# -1#) = negateInteger x timesInteger (S# -1#) y = negateInteger y timesInteger (S# x#) (S# y#) = case mulIntMayOflo# x# y# of 0# -> S# (x# *# y#) _ -> timesInt2Integer x# y# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 02:07:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 02:07:48 -0000 Subject: [GHC] #9438: panic: loading archives not supported In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.d6e44a2d213d2cb10674d3624af7978a@haskell.org> #9438: panic: loading archives not supported -----------------------------------+---------------------------------- Reporter: egl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8164 Differential Revisions: | -----------------------------------+---------------------------------- Comment (by egl): atlas was installed by Macports. This should install atlas: {{{ sudo port install atlas }}} If not, then this will drag atlas in as a dependency. {{{ sudo port install octave }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 02:13:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 02:13:19 -0000 Subject: [GHC] #8403: Pretty-printing of long types In-Reply-To: <047.792ac96369079bc46b579fe906221406@haskell.org> References: <047.792ac96369079bc46b579fe906221406@haskell.org> Message-ID: <062.ede332f5123844c8564825b6c304f22e@haskell.org> #8403: Pretty-printing of long types -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: #9428 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9428 Comment: Thank you for the report. #9428 looks like another instance of this bug, but then for error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 02:17:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 02:17:05 -0000 Subject: [GHC] #9428: Pretty printer bad formatting In-Reply-To: <047.0c4467a917eff36078c41806463d1f16@haskell.org> References: <047.0c4467a917eff36078c41806463d1f16@haskell.org> Message-ID: <062.1574e06320f4e0d3cce3ef99f0e0d6a5@haskell.org> #9428: Pretty printer bad formatting -------------------------------------+------------------------------------- Reporter: terrelln | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: pretty print Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: #8403 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * component: Driver => Compiler * related: => #8403 Comment: This seems like another instance of #8403 (Pretty-printing of long types). I added a link back to this ticket from there. terrelln: thanks for the bug report. Please reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 02:20:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 02:20:49 -0000 Subject: [GHC] #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations In-Reply-To: <047.18a7617988133530c5da58a1eb2182c3@haskell.org> References: <047.18a7617988133530c5da58a1eb2182c3@haskell.org> Message-ID: <062.e55edea0fe0429e766a6fcbe5f1473fe@haskell.org> #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 02:53:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 02:53:26 -0000 Subject: [GHC] #9406: unexpected failure for T7837(profasm) In-Reply-To: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> References: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> Message-ID: <057.7db6f1e9a837083a99857dbd87b93e34@haskell.org> #9406: unexpected failure for T7837(profasm) -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: T7837 Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: T7837 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple Comment: Also fails on linux. To run the test manually: `LANG=C make fulltest stage=2 TEST=T7837 WAY=prof`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 02:55:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 02:55:42 -0000 Subject: [GHC] #9405: Ticky results should be displayed even during interrupts (Ctrl-c) In-Reply-To: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> References: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> Message-ID: <067.90570e8c7557d763a54ca367d4ba8c2b@haskell.org> #9405: Ticky results should be displayed even during interrupts (Ctrl-c) -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: Component: Profiling | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Profiling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 07:47:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 07:47:33 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma Message-ID: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- So I have a function "a", which uses another function "b" from another module. * Step 1. I benchmark its performance and get 250ns. * Step 2. I go and put the "INLINE" pragma on the function "b", run the benchmark again and get 500ns. That is twice as long. * Step 3. I go and add an explicit invocation of the [http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC- Exts.html#v:inline inline] function over function "b" in function "a" and finally get the desired optimization: 208ns. You can reproduce the issue by executing {{{cabal bench decoding --benchmark-options=numeric}}} after cloning the trees of the following commits: * [https://github.com/nikita-volkov/postgresql- binary/commit/31e08b4f6887445c28118d25f9da808e7ca9fc86 Step 1] * [https://github.com/nikita-volkov/postgresql- binary/commit/8f29b8daebc3161dc0fa35fbd70d3f3305370a4e Step 2] * [https://github.com/nikita-volkov/postgresql- binary/commit/3d3e4378bcd8ea85cda868d6a4bf07a76a9cad2c Step 3] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 08:17:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 08:17:54 -0000 Subject: [GHC] #9763: Implement Foldable methods for Array directly In-Reply-To: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> References: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> Message-ID: <060.ea7412841ac62a3a21cae830e4d865bf@haskell.org> #9763: Implement Foldable methods for Array directly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D459 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"212a350547e950cc5be465a3d76e346ef14bf2ab/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="212a350547e950cc5be465a3d76e346ef14bf2ab" Improve `Foldable` instance for `Array` Previously, `Array`s were simply converted to lists, and the list methods used. That works acceptably well for `foldr` and `foldr1`, but not so sensibly for most other things. Left folds ended up "twisted" the way they are for lists, leading to surprising performance characteristics. Moreover, this implements `length` and `null` so they check the array size directly. Finally, a test is added to the testsuite ensuring the overridden `Foldable` methods agree with their expected default semantics. Addresses #9763 Reviewed By: hvr, austin Differential Revision: https://phabricator.haskell.org/D459 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 09:27:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 09:27:07 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma In-Reply-To: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> References: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> Message-ID: <062.22eefb2f3f65255da13a0d13a56193e9@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I can see that is frustrating. There are a lot of dependencies here. (Though, happily, I believe that one can run your benchmark without having any C stuff installed eg postgres. Is that right?) But still, there's a lot of stuff. Could you * compile just the offending module (which is `Decoder.hs` I think), * on its own, * preferably with only the definition for `numeric` (which is the offending one I think) * with the extra flags `-dverbose-core2core -ddump-inlinings` and save the three results for Step 1/2/3 attached to this ticket? That would mean I could take a look without reproducing the setup. Another thing that would be revealing would be to add `-ticky` to the command line when compiling; and `+RTS -rstep1.ticky` to the command line when running. And then add the `.ticky` files to the ticket. That should show up where the performance differences are occurring without affecting anything. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 09:37:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 09:37: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.3143404a8fbc8663b299fe36b66effa5@haskell.org> #9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jcpetruzza): As another example of why `trace` shouldn't be strict, consider the following: {{{#!hs f xs = trace (show xs) $ g 0 xs where g n [] = n g n (x:xs) = g (n+1) xs main = print $ f [1..] }}} Because `trace` is strict, no output will be shown, which hides the fact that `f` is actually being called but with invalid input. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 09:51:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 09:51:10 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.3e4be55b0b34aa10327a28a57f7a0a06@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"63a9d9387f27e5842bed5946c5f1381f209d2918/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="63a9d9387f27e5842bed5946c5f1381f209d2918" Fix `integer-gmp2` compilation with GMP 4.x (#9281) GMP 4.x didn't provide the `mp_bitcnt_t` typedef yet, so we locally define one if GMP 4.x is detected. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 10:07:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 10:07:56 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma In-Reply-To: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> References: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> Message-ID: <062.690d8c41e1238789539eb1586f5c4107@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mojojojo): > I believe that one can run your benchmark without having any C stuff installed eg postgres. Is that right? Yes. Only Haskell dependencies in the benchmark build target. > But still, there's a lot of stuff. I'll try to approach this some time soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 10:28:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 10:28:58 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.6d6dfc745d0c5bb08ef31a12c40444a8@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D469 | -------------------------------------+------------------------------------- Comment (by simonpj): Can you just lay out what the "refactoring task" is? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 11:34:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 11:34:59 -0000 Subject: [GHC] #9763: Implement Foldable methods for Array directly In-Reply-To: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> References: <045.d23ab50f37b89311256e63d9a35b0649@haskell.org> Message-ID: <060.da07b6f5ceade342ef42dc6f12862fe6@haskell.org> #9763: Implement Foldable methods for Array directly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D459 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 11:40:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 11:40:57 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma In-Reply-To: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> References: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> Message-ID: <062.290ff1ffa53aaa4735aee21b5a7fc872@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mojojojo): I've narrowed the code down as much as possible and [https://github.com /nikita-volkov/postgresql-binary/tree/ghc-issue-9798 published it in a dedicated branch]. You'll find that latest commits reproduce the issue in the narrowed down code step by step. Also you'll find the according dumps and ticky reports attached to this issue. I've generated them by passing the according GHC and runtime flags to Cabal, I hope this doesn't matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:36:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:36:39 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.1687505ed7a13cdb8fc7c147f3ec08bf@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:36:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:36:47 -0000 Subject: [GHC] #9776: -frule-check flag not recognized without parameter In-Reply-To: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> References: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> Message-ID: <063.e569f36027024906157fdbc3b955c1a4@haskell.org> #9776: -frule-check flag not recognized without parameter -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) warning at compile-time | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:42:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:42:30 -0000 Subject: [GHC] #8308: Resurrect ticky code for counting constructor arity In-Reply-To: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> References: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> Message-ID: <063.ecd5619642692e627f054897567913f5@haskell.org> #8308: Resurrect ticky code for counting constructor arity -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: mlen Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:41:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:41:54 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.6f7c36687fdc969ac900152271491ff0@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4114 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:42:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:42:41 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.1532df377cb2766c6107e26340f5f43f@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:41:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:41:58 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.731e3045d4558c8888a3357584017bde@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.10.4 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #2258 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:42:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:42:16 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.e1f22fb1570b4126e92b3b1b2793177b@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: deriving, Resolution: | newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: deriving => deriving, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:43:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:43:15 -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.c0724287840605341c5ecb154ba78ea1@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:43:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:43:04 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.edcb474730e004f3cb936be30df7f6f0@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D337 | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:42:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:42:50 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.6ce3b29f17e440664751e4e50e5a23db@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 13:59:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 13:59:07 -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.fbf8b8600055419198da04fd9e61c5de@haskell.org> #8274: Core pretty-printer doesn't print # on unboxed literals -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 14:00:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 14:00:29 -0000 Subject: [GHC] #8750: Invalid identifier generated with Template Haskell not rejected In-Reply-To: <048.b4360da9d8570bad1f1bddfa9464dc6c@haskell.org> References: <048.b4360da9d8570bad1f1bddfa9464dc6c@haskell.org> Message-ID: <063.dc1c243d7bcf616752c89777ad050cbe@haskell.org> #8750: Invalid identifier generated with Template Haskell not rejected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 14:04:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 14:04:39 -0000 Subject: [GHC] #9009: Confusing error message when loading package with TH In-Reply-To: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> References: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> Message-ID: <063.688d8bbb5f36aaeb604e26471811e16f@haskell.org> #9009: Confusing error message when loading package with TH -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Package | Version: 7.8.2 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Interesting that you can't reproduce this with 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 14:05:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 14:05:29 -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.6c9a2f161d862d3e4386fcbd98b3c219@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer Comment: Replying to [comment:3 nomeata]: > Wasn?t there a ticket asking for more structured splice output, i.e. dumping it to a separate file #8624 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 14:08:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 14:08:49 -0000 Subject: [GHC] #9392: "\n" is displayed weirdly in error messages In-Reply-To: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> References: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> Message-ID: <066.9f4c1a864775d2a45c8d429e67803c56@haskell.org> #9392: "\n" is displayed weirdly in error messages -------------------------------------+------------------------------------- Reporter: | Owner: Artyom.Kazak | Status: new Type: bug | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #9681 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * related: => #9681 Comment: The problem with a newline at the end of a string was fixed in #9681, slated for GHC 7.10.1. Let's leave this issue open for the formatting issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 14:20:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 14:20:56 -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.a18378c2248411cacd7e5b6bcb1e6ae3@haskell.org> #17: Separate warnings for unused local and top-level bindings -------------------------------------+------------------------------------- Reporter: magunter | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: None Component: Compiler | Keywords: -fwarn-unused- Resolution: None | binds newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3283 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: -fwarn-unused-binds => -fwarn-unused-binds newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 14:21:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 14:21:45 -0000 Subject: [GHC] #1262: RecursiveDo in Template Haskell In-Reply-To: <062.2857e038d8ba06eaa6e83d19ada8ff7e@haskell.org> References: <062.2857e038d8ba06eaa6e83d19ada8ff7e@haskell.org> Message-ID: <077.5ee1dd1446304b690f86baf8fbddbd57@haskell.org> #1262: RecursiveDo in Template Haskell -------------------------------------+------------------------------------- Reporter: | Owner: philip.weaver@? | Status: new Type: feature | Milestone: ? request | Version: 6.6 Priority: normal | Keywords: newcomer Component: Template | Architecture: Unknown/Multiple Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 14:21:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 14:21:53 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.8f09544f263a4f11ebeb2916640913fd@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature | Status: new request | Milestone: ? Priority: normal | Version: None Component: Compiler | Keywords: newcomer (Type checker) | Architecture: Unknown/Multiple Resolution: None | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 14:25:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 14:25:05 -0000 Subject: [GHC] #9095: make sdist picks up test files In-Reply-To: <045.5bc6b697ad76318e7d59aba1132cfee1@haskell.org> References: <045.5bc6b697ad76318e7d59aba1132cfee1@haskell.org> Message-ID: <060.105d0d763fb244f31e2292de5e992820@haskell.org> #9095: make sdist picks up test files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.9 System | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 14:33:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 14:33:21 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.bedb82de69327a0109c9aaa02cc7d380@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 15:01:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 15:01:51 -0000 Subject: [GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) In-Reply-To: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> References: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> Message-ID: <059.c721c84b82484c66a06b788006e05402@haskell.org> #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Runtime | hour) crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => patch * milestone: => 7.10.1 Comment: scpmw's explanation sounds reasonable. Does GHC actually support LLVM 3.2? For example, in https://ghc.haskell.org/trac/ghc/ticket/9555#comment:7, rwbarton says: > There are known problems with LLVM 3.2 and GHC, can you try with 3.3 or 3.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 15:05:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 15:05:27 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.b8fb8958cd0e893cd8a2f3d7c23c1863@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): Maybe {{{ src/Numerical/OpenBLAS/BLAS.hs:41:44: A pattern match on a GADT requires {-# LANGUAGE GADTs #-} or {-# LANGUAGE TypeFamilies #-} }}} ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 15:07:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 15:07:31 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma In-Reply-To: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> References: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> Message-ID: <062.1f76a647393b123469d408bf56b34126@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Did you use `-ddump-inlinings`? Could you add `-ddump-occur-anal -ddump- stg`. Can you combine stdout and stderr together? I'm not sure which is which, because directory `step2/` contains files labelled `step3` and vice versa! Since you are zipping, you could bundle all three in one. Thanks! As you'll see, the ticky numbers are revealing. But it looks as if step1 allocates least. Is step3 really faster? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 15:41:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 15:41:02 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.71fccce212cbb2667a8c9e2832b6450b@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: pattern synonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"7f929862388afd54043d59b37f2f5375c5315344/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7f929862388afd54043d59b37f2f5375c5315344" If pattern synonym is bidirectional and its type is some unboxed type T#, generate a worker function of type Void# -> T#, and redirect the wrapper (via a compulsory unfolding) to the worker. Fixes #9732. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 15:41:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 15:41:43 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.b7ed05711481fde0985fc85c59b9349c@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: pattern synonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: patch => merge * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 15:42:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 15:42:41 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.2ad49fd1b36e5aa35a222a8160e392d4@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: pattern synonyms Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * milestone: 7.10.1 => 7.8.4 Comment: Note that `7f929862..638991` all need to be cherry-picked to the 7.8 branch for this to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 16:36:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 16:36:14 -0000 Subject: [GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) In-Reply-To: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> References: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> Message-ID: <059.68af8d0bd28f0f780ed611bf09594248@haskell.org> #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Runtime | hour) crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by scpmw): LLVM 3.2 isn't blacklisted, so I think we are still "supporting" it, at least on paper. The comment might be referring to #7694? It's quite possible that this is actually the fix for that issue - crashes at virtually random places sounds about right. All I can say is that after applying the patch I was able to run the full test suite using LLVM 3.2. Without it, we get at least a dozen segfaults in there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 17:30:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 17:30:17 -0000 Subject: [GHC] #8109: Type family patterns should support as-patterns. In-Reply-To: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> References: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> Message-ID: <065.3ec2f85fdbbd53b52c63652a55e950ba@haskell.org> #8109: Type family patterns should support as-patterns. -------------------------------------+------------------------------------- Reporter: | Owner: carlhowells | Status: new Type: feature | Milestone: request | Version: 7.6.3 Priority: normal | Keywords: newcomer Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 18:02:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 18:02:32 -0000 Subject: [GHC] #8308: Resurrect ticky code for counting constructor arity In-Reply-To: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> References: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> Message-ID: <063.0b45d2ef74689473495511200018ae63@haskell.org> #8308: Resurrect ticky code for counting constructor arity -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: mlen Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mlen): The work in progress version is available at: https://github.com/mlen/ghc/tree/ticky Recently I haven't got time to make any progress. I'll probably get something done during the weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 18:03:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 18:03:57 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma In-Reply-To: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> References: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> Message-ID: <062.a63cc315375173f7ef120621bab45a15@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mojojojo): I actually tried to upload it as a single archive, only to find out that you have a limit of 250KB for a single upload here. So I might have messed up with the archive titles later, the dump and picky files though should have been correct. Concerning your request I'll try to post back with updates soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 18:07:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 18:07:56 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.c294e91585cfc1f941dea5e72ecc39d2@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: crockeea: I am not able to reproduce your issue on Ubuntu x86_64. {{{ $ cp /usr/lib/x86_64-linux-gnu/libbsd.so -H . $ touch Foo.hs $ ghc-7.8.2 --interactive Foo *.so GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) libbsd.so ... done final link ... done [1 of 1] Compiling Main ( Foo.hs, interpreted ) Ok, modules loaded: Main. }}} Which OS and architecture are you using? Could you supply the most simple source for `mylib.so` with which you encounter this issue, including build and run instructions. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 18:08:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 18:08:45 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma In-Reply-To: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> References: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> Message-ID: <062.78b2c43c37cfe42bc37be29b7597d09e@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mojojojo): I bet it won't be a problem for you to inspect the problem yourself now though, since the codebase is quite narrowed down now: https://github.com/nikita-volkov/postgresql-binary/tree/ghc-issue-9798 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 18:12:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 18:12:14 -0000 Subject: [GHC] #9385: Additions to Control.Monad In-Reply-To: <042.43d25471e6c4c7993c2ad33f337aca33@haskell.org> References: <042.43d25471e6c4c7993c2ad33f337aca33@haskell.org> Message-ID: <057.d94a313b062f87d5cfb1ed89cdde48cc@haskell.org> #9385: Additions to Control.Monad -------------------------------------+------------------------------------- Reporter: olf | Owner: ekmett Type: feature | Status: infoneeded request | Milestone: Priority: low | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => infoneeded Comment: olf: did you submit any proposal to the libraries mailinglist for this? See also: https://www.haskell.org/haskellwiki/Library_submissions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 18:26:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 18:26:18 -0000 Subject: [GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error In-Reply-To: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> References: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> Message-ID: <062.8958d17fbce4ba09abfe2cd2675ea872@haskell.org> #9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request Comment: See the function `unsupportedExtnError` in the file `compiler/main/HeaderInfo.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 20:08:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 20:08:01 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.a3d084376ca677655121da5da2a60d19@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * cc: hvr (added) * failure: GHCi crash => Other * status: infoneeded => new * component: Compiler => GHCi * version: 7.8.2 => 7.8.3 Comment: I'm still experiencing this issue with ghc-7.8.3-x86-64-unknown-linux and gcc-4.8.2. Consider the following C file, mul.c: {{{#!c //zipWith (*) void mul (int* a, int* b, int n) { int i; for(i = 0; i < n; i++) { a[i] = a[i]*b[i]; } } }}} At the terminal (where Foo.hs is empty): {{{ > gcc -c mul.c > gcc -shared -o mylib.so *.o > ghci Foo *.o 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. Loading object (dynamic) mylib.so ... failed. : user specified .o/.so/.DLL could not be loaded (mylib.so: cannot open shared object file: No such file or directory) Whilst trying to load: (dynamic) mylib.so Additional directories searched: (none) > mkdir Temp > cp *.so Temp/ > ghci Foo Temp/*.o 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. Loading object (static) Temp/*.o ... not found final link ... done [1 of 1] Compiling Main ( Foo.hs, interpreted ) Ok, modules loaded: Main. *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 20:15:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 20:15:53 -0000 Subject: [GHC] #9796: Implement amap/coerce rule for `Array` In-Reply-To: <045.6e18c11ce0de8ebcd631eb7d710d6e30@haskell.org> References: <045.6e18c11ce0de8ebcd631eb7d710d6e30@haskell.org> Message-ID: <060.9b754c2fd3e3c0bfe5adabef8c46c4e2@haskell.org> #9796: Implement amap/coerce rule for `Array` -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D471 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"603b7be7bd3abaf0e2c210e8d9015b1d613b4715/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="603b7be7bd3abaf0e2c210e8d9015b1d613b4715" Implement amap/coerce for Array (re #9796) Implement an `amap`/`coerce` rule in `GHC.Arr` to match the `map`/`coerce` rule in GHC.Base. In order to do so, delay inlining `amap` until phase 1. To prevent the inlining delay from causing major inefficiencies due to missed list fusion, rewrite `amap` to avoid relying on list fusion. This has the extra benefit of reducing the size of the compiled amap code by skipping the impossible case of an array with a negative size. Reviewed By: nomeata Differential Revision: https://phabricator.haskell.org/D471 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 20:43:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 20:43:19 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma In-Reply-To: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> References: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> Message-ID: <062.a189d0a5e58300f13bb8f29b9d9a3289@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mojojojo): I've ran this thing with the new flags and capturing stderr too. You'll find the files in the root of the tree on the same branch: https://github.com/nikita-volkov/postgresql-binary/tree/ghc-issue-9798 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 21:32:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 21:32:24 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.711c2a50d0cd4bc00bc360ace59057ff@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D469 | -------------------------------------+------------------------------------- Comment (by goldfire): Simplifying the rule for `($)`, as you requested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 21:33:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 21:33:59 -0000 Subject: [GHC] #8750: Invalid identifier generated with Template Haskell not rejected In-Reply-To: <048.b4360da9d8570bad1f1bddfa9464dc6c@haskell.org> References: <048.b4360da9d8570bad1f1bddfa9464dc6c@haskell.org> Message-ID: <063.b526e77d7958fa10713e2cc75ff7bca7@haskell.org> #8750: Invalid identifier generated with Template Haskell not rejected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: newcomer Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #7484. Closing... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 21:35:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 21:35:20 -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.579140978bf78d65ed115a25f597947a@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer Comment: I'm happy to advise a newcomer if they want to take this one on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 21:37:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 21:37:16 -0000 Subject: [GHC] #9518: Improve error message for unacceptable role annotations In-Reply-To: <047.7d86d581088086ed2263f989759fcf30@haskell.org> References: <047.7d86d581088086ed2263f989759fcf30@haskell.org> Message-ID: <062.9a71274d8d2d4891606c0c9c0b41fbdb@haskell.org> #9518: Improve error message for unacceptable role annotations -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: infoneeded request | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: newcomer (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer Comment: This is appropriate for a newcomer to GHC, but who has a decent understanding of roles. I am happy to advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 21:37:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 21:37:45 -0000 Subject: [GHC] #2526: Warn about missing signatures only for exported functions In-Reply-To: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> References: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> Message-ID: <069.429e92540aa344ee71947bc79df259b8@haskell.org> #2526: Warn about missing signatures only for exported functions -------------------------------------+------------------------------------- Reporter: | Owner: fergushenderson | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.8.3 Priority: lowest | Keywords: newcomer Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 21:38:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 21:38:27 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command In-Reply-To: <047.01134e82983fb263026aa29a14aa8897@haskell.org> References: <047.01134e82983fb263026aa29a14aa8897@haskell.org> Message-ID: <062.3b31d98b40552de8c9afd701e0d577fe@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: ghci newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: ghci => ghci newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 21:39:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 21:39:25 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.89b0723491dd70d7709612dd39b2998a@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.1 Haskell | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 13 21:49:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Nov 2014 21:49:42 -0000 Subject: [GHC] #7484: Template Haskell allows building invalid record fields/names In-Reply-To: <045.397b38fee58f310a634c2d78baa84281@haskell.org> References: <045.397b38fee58f310a634c2d78baa84281@haskell.org> Message-ID: <060.b1c946176b8b2be6be68b082a1d23e2a@haskell.org> #7484: Template Haskell allows building invalid record fields/names -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8750 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D431 | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #8750 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 00:00:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 00:00:50 -0000 Subject: [GHC] #9796: Implement amap/coerce rule for `Array` In-Reply-To: <045.6e18c11ce0de8ebcd631eb7d710d6e30@haskell.org> References: <045.6e18c11ce0de8ebcd631eb7d710d6e30@haskell.org> Message-ID: <060.34e788d27823c7e21e305e078e3fa216@haskell.org> #9796: Implement amap/coerce rule for `Array` -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D471 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 00:19:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 00:19:05 -0000 Subject: [GHC] #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" Message-ID: <045.33b56a4389644150958519a6a326156f@haskell.org> #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: #9360 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ $ ./ghci -e '2 + 2' ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141108 for x86_64-unknown-linux): ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141108 for x86_64-unknown-linux): v_unsafeGlobalDynFlags: not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The actual expression does not matter, using `''` yields the same result. This bug does is not present in 7.8.3. See also #9360 for a feature request concerning `ghci -e`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 00:20:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 00:20:06 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.e4c022e1183683e63371e21f55817a82@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9799 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * component: Compiler => GHCi * related: => #9799 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 00:50:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 00:50:28 -0000 Subject: [GHC] #9350: Consider using xchg instead of mfence for CS stores In-Reply-To: <044.20ad8d34f8b6b8a13d3ff80072b8a8e7@haskell.org> References: <044.20ad8d34f8b6b8a13d3ff80072b8a8e7@haskell.org> Message-ID: <059.7410193978510cbb633764eeab736867@haskell.org> #9350: Consider using xchg instead of mfence for CS stores -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (NCG) | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * failure: None/Unknown => Runtime performance bug * component: Compiler => Compiler (NCG) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 01:08:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 01:08:42 -0000 Subject: [GHC] #9347: forkProcess does not acquire global handle locks In-Reply-To: <044.faeca2d8b88cc27819d6e9b9f2f3ebd0@haskell.org> References: <044.faeca2d8b88cc27819d6e9b9f2f3ebd0@haskell.org> Message-ID: <059.518fde0a52904ef722782634b18ffbe8@haskell.org> #9347: forkProcess does not acquire global handle locks -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * failure: None/Unknown => Incorrect result at runtime * component: Compiler => Runtime System * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 01:16:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 01:16:40 -0000 Subject: [GHC] #9341: Evaluate default CPUs setting for validate In-Reply-To: <046.b9cefa8bb3e5226f52c77645c82efc6d@haskell.org> References: <046.b9cefa8bb3e5226f52c77645c82efc6d@haskell.org> Message-ID: <061.34b1b4851f6fbe4e4733a70868c5e741@haskell.org> #9341: Evaluate default CPUs setting for validate -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D146 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * differential: => Phab:D146 * resolution: => fixed * milestone: => 7.10.1 Comment: This has since been implemented. `./validate` now sets `THREADS=CPUS+1`, and `CPUS` is determined dynamically. {{{ commit f328890021253c426b7450b6c5a1061d25f6219b Author: Sergei Trofimovich Date: Tue Aug 19 16:54:13 2014 +0300 validate: add simple CPU count autodetection Summary: Signed-off-by: Sergei Trofimovich Test Plan: ran ./validate on linux Reviewers: austin Reviewed By: austin Subscribers: phaskell, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D146 }}} See also: https://www.haskell.org/pipermail/ghc-devs/2014-August/006018.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 01:31:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 01:31:32 -0000 Subject: [GHC] #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". In-Reply-To: <046.9f9b875883fbae34683c004793d8a328@haskell.org> References: <046.9f9b875883fbae34683c004793d8a328@haskell.org> Message-ID: <061.a7473b47a461da445234ac24aa8cdd10@haskell.org> #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". -------------------------------------+------------------------------------- Reporter: frerich | Owner: ekmett Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => wontfix Comment: Here's a link to the library submission. The discussion never reached a conclusion, as far as I can tell: https://www.haskell.org/pipermail/libraries/2014-July/023283.html Please reopen if this proposal ever gets accepted in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 01:38:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 01:38:20 -0000 Subject: [GHC] #9323: Confusing type error behaviour In-Reply-To: <046.c75a150676320e99ffc6a8acf4082499@haskell.org> References: <046.c75a150676320e99ffc6a8acf4082499@haskell.org> Message-ID: <061.fbc2ebbb9fef65fd2093927b992f46df@haskell.org> #9323: Confusing type error behaviour -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T9323.hs | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * component: Compiler => Compiler (Type checker) * testcase: => typecheck/should_fail/T9323.hs * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 01:46:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 01:46:12 -0000 Subject: [GHC] #9322: Modify readProcess[WithExitCode] to allow setting current directory In-Reply-To: <048.5e54c14d88e053ace878139be5424c0e@haskell.org> References: <048.5e54c14d88e053ace878139be5424c0e@haskell.org> Message-ID: <063.707f8510124623c704462b48c02966fd@haskell.org> #9322: Modify readProcess[WithExitCode] to allow setting current directory -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: ekmett Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => wontfix * milestone: 7.10.1 => Comment: Thank you for your report. The `process` bugtracker is at https://github.com/haskell/process nowadays. But the change you are requesting would have to go through the [https://www.haskell.org/haskellwiki/Library_submissions library submission process] first, so please send a proposal to libraries at ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 02:10:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 02:10:10 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions In-Reply-To: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> References: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> Message-ID: <062.06683b09a161ea434e58c415e40d0f38@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Compiling the code from the ticket description now shows only the expected error message: {{{ $ ghc-7.9.20141108 test.hs [1 of 1] Compiling Test ( test.hs, test.o ) test.hs:11:5: Couldn't match type ?Bool? with ?Char? Expected type: F Int Actual type: Char In the pattern: 'x' In an equation for ?bar?: bar 'x' = () }}} A regression test is still missing, otherwise this ticket could be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 02:47:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 02:47:29 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page (was: Huge space leak of GHC API 7.8.x) In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.cf606d03688692bc5bea6ccf61451368@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: 7.10.1 Priority: high | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: GHC API => Compiler Comment: The comment in `rts/Linker.c` that rwbarton referred to in comment:10: {{{ /* We can't mmap from the archive directly, as object files need to be 8-byte aligned but files in .ar archives are 2-byte aligned. When possible we use mmap to get some anonymous memory, as on 64-bit platforms if we use malloc then we can be given memory above 2^32. In the mmap case we're probably wasting lots of space; we could do better. */ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 02:58:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 02:58:55 -0000 Subject: [GHC] #9307: LLVM vs NCG: floating point numbers close to zero have different sign (was: wave4main in nofib fails) In-Reply-To: <042.6d7e0c37dce6aa97cc1ca70e5fb349be@haskell.org> References: <042.6d7e0c37dce6aa97cc1ca70e5fb349be@haskell.org> Message-ID: <057.67b2380f212a9a28398d628bae2640f1@haskell.org> #9307: LLVM vs NCG: floating point numbers close to zero have different sign -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (NCG) | Keywords: wave4main Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: wave4main | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: NoFib benchmark suite => Compiler (NCG) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 03:57:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 03:57:54 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.a4f8abe4c5069bf66ddb16e309f9ded6@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4114 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bheklilr): I'd be willing to try to take this on as my first contribution to GHC (along with [https://ghc.haskell.org/trac/ghc/ticket/4114 4114] since it's rather related) if someone would be willing to help me along. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 12:59:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 12:59:57 -0000 Subject: [GHC] #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" In-Reply-To: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> References: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> Message-ID: <060.8bfc933bac194c69cd9f8ac72264b55e@haskell.org> #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" -------------------------------------+------------------------------------- Reporter: jfeltz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: :set -XCPP | followed by :unset -XCPP | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: Also consider `:unset -XNoExt`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 15:15:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 15:15:35 -0000 Subject: [GHC] #9800: Panic when building HEAD with BuildFlavour=quickest: "Can't use Integer in integer-*" Message-ID: <045.7ea66f0ee84308012af7c56c8492b8b1@haskell.org> #9800: Panic when building HEAD with BuildFlavour=quickest: "Can't use Integer in integer-*" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ $ uname -op x86_64 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ git log --oneline | head -1 fa75309 Update .mailmap $ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -this-package-key integ_2MbWUstH60IEgCAexOk3v3 -hide-all-packages -i -ilibraries/integer-gmp2/src/ -ilibraries/integer-gmp2/dist- install/build -ilibraries/integer-gmp2/dist-install/build/autogen -Ilibraries/integer-gmp2/dist-install/build -Ilibraries/integer-gmp2/dist- install/build/autogen -Ilibraries/integer-gmp2/include -optP-include -optPlibraries/integer-gmp2/dist-install/build/autogen/cabal_macros.h -package-key ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -this-package-key integer-gmp -Wall -XHaskell2010 -O0 -fasm -no-user-package-db -rtsopts -odir libraries/integer-gmp2/dist-install/build -hidir libraries/integer-gmp2 /dist-install/build -stubdir libraries/integer-gmp2/dist-install/build -dynamic-too -c libraries/integer-gmp2/src//GHC/Integer/Type.hs -o libraries/integer-gmp2/dist-install/build/GHC/Integer/Type.o -dyno libraries/integer-gmp2/dist-install/build/GHC/Integer/Type.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20141114 for x86_64-unknown-linux): Can't use Integer in integer-* Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/integer-gmp2/dist- install/build/GHC/Integer/Type.o] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 16:02:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 16:02:31 -0000 Subject: [GHC] #9800: Panic when building HEAD with BuildFlavour=quickest: "Can't use Integer in integer-*" In-Reply-To: <045.7ea66f0ee84308012af7c56c8492b8b1@haskell.org> References: <045.7ea66f0ee84308012af7c56c8492b8b1@haskell.org> Message-ID: <060.a31d9bf689fbbd5738285dd3438174af@haskell.org> #9800: Panic when building HEAD with BuildFlavour=quickest: "Can't use Integer in integer-*" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Using `BuildFlavour=quick` does work. Note to self: after this is fixed, also check #9302. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 16:17:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 16:17:19 -0000 Subject: [GHC] #9287: changed dependency generation In-Reply-To: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> References: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> Message-ID: <060.d397f6399e9a5ae6a41af1520d3c4ed5@haskell.org> #9287: changed dependency generation -------------------------------------+------------------------------------- Reporter: maeder | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: #9749, #7381 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: task => bug * component: Documentation => Driver * related: => #9749, #7381 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 16:19:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 16:19:07 -0000 Subject: [GHC] #9749: ghc -M 7.8 does not add underscores when -dep-suffix is used In-Reply-To: <042.ec0d8eacc55debae81fec5cb658ef211@haskell.org> References: <042.ec0d8eacc55debae81fec5cb658ef211@haskell.org> Message-ID: <057.ff01d971c0f3b1c897e75ad4c81cdb63@haskell.org> #9749: ghc -M 7.8 does not add underscores when -dep-suffix is used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: #9287 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * component: Build System => Driver * related: #7381 => #9287 * milestone: 7.8.4 => Comment: nh2: please cc yourself to #9287. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 16:20:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 16:20:46 -0000 Subject: [GHC] #7381: Build failure with BuildFlavour = prof In-Reply-To: <047.aa1b992407c04eb83593ab3d072f1bff@haskell.org> References: <047.aa1b992407c04eb83593ab3d072f1bff@haskell.org> Message-ID: <062.1063892d0f52ae9114a88a466ed462eb@haskell.org> #7381: Build failure with BuildFlavour = prof -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: #9749 GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * os: MacOS X => Unknown/Multiple * related: => #9749 * milestone: 7.8.4 => Comment: nh2: I'm moving this discussion to #9749, and reclosing this ticket here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 16:34:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 16:34:08 -0000 Subject: [GHC] #9801: Make listArray fuse Message-ID: <045.f98eb8db084a68856be2223df4e40101@haskell.org> #9801: Make listArray fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Runtime than a day) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D474 -------------------------------------+------------------------------------- `GHC.Arr.listArray` does not currently fuse with a good list producer. Let's make that happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 16:34:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 16:34:21 -0000 Subject: [GHC] #9801: Make listArray fuse In-Reply-To: <045.f98eb8db084a68856be2223df4e40101@haskell.org> References: <045.f98eb8db084a68856be2223df4e40101@haskell.org> Message-ID: <060.719ccbf50576600255f34ae6226065be@haskell.org> #9801: Make listArray fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D474 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 16:35:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 16:35:38 -0000 Subject: [GHC] #8701: Update libffi-tarballs to latest libffi In-Reply-To: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> References: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> Message-ID: <060.1a4fb570ce920d924907caba0c1f615f@haskell.org> #8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc1 (FFI) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:08:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:08:59 -0000 Subject: [GHC] #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types In-Reply-To: <045.54c1b52407bd07f539504f3c758ce78d@haskell.org> References: <045.54c1b52407bd07f539504f3c758ce78d@haskell.org> Message-ID: <060.fb15e91c6b40d6eb5cef0ce990324a65@haskell.org> #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Ah. I misread your proposal. Doing it 'pointwise' on a case by case basis like that is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:09:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:09:15 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.00b1ae89b3b3a591923f75fdf0a5fdc3@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------ Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9286 Differential Revisions: | -------------------------------------+------------------------------------ Changes (by thomie): * related: => #9286 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:10:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:10:42 -0000 Subject: [GHC] #9286: ghc-7.9.20140707 fails testsuite on OS X (10.10) Yosemite In-Reply-To: <042.e5f3288a9db022942dd41ba3f45a10c9@haskell.org> References: <042.e5f3288a9db022942dd41ba3f45a10c9@haskell.org> Message-ID: <057.5175b1c4f80332928251bcd4a78c44e1@haskell.org> #9286: ghc-7.9.20140707 fails testsuite on OS X (10.10) Yosemite -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: duplicate | Keywords: testsuite Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: #9389 T5435_dyn_asm T4801 T6048 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9389 Comment: Let's combine all these lists of full test suite failures in #9389. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:13:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:13:59 -0000 Subject: [GHC] #9285: IO manager startup procedure somewhat odd In-Reply-To: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> References: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> Message-ID: <059.4138e713227871f6910e38bb9cb74de3@haskell.org> #9285: IO manager startup procedure somewhat odd -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * owner: => simonmar * component: Compiler => Runtime System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:15:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:15:15 -0000 Subject: [GHC] #9782: Do not by default set ekmett as owner for 'Core libraries' In-Reply-To: <045.9a4eaf64f0d6b763bc80d89ea22b10c3@haskell.org> References: <045.9a4eaf64f0d6b763bc80d89ea22b10c3@haskell.org> Message-ID: <060.0379af5a9c7bd38b7545e27ee085112d@haskell.org> #9782: Do not by default set ekmett as owner for 'Core libraries' -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Do not set simononmar by default as owner of 'Runtime system' tickets either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:25:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:25:18 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.f7500ebb5f6027783335af15498f7cda@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4114 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Just do it :-) If you run into problems or have any questions ask here, on ghc-devs, or in #ghc IRC channel. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:34:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:34:27 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.57b0aba52cd902912533b671ae61ca8b@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4114 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by VictorDenisov): Replying to [comment:17 bheklilr]: > I'd be willing to try to take this on as my first contribution to GHC (along with [https://ghc.haskell.org/trac/ghc/ticket/4114 4114] since it's rather related) if someone would be willing to help me along. I insist this is my ticket) I assigned it to me when nobody was. Please find another unassigned ticket assign it to you and work on it. (4114 I also assigned to me since they are related) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:39:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:39:41 -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.4225e8540df2091724b915a22ca0927e@haskell.org> #8274: Core pretty-printer doesn't print # on unboxed literals -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: detrumi Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by detrumi): * owner: => detrumi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:56:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:56:43 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.834025e1d31f0c8ff5e55eeef6e91bc3@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.6.3 Component: Compiler | Keywords: Debian (FFI) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Kritzefitz): I will demonstrate with the curl package: Assuming I have installed the libcurl3 package but not the libcurl-dev package. This means I have the following shared libraries belonging to curl installed: /usr/lib/i386-linux-gnu/libcurl-gnutls.so.3 /usr/lib/i386-linux-gnu/libcurl.so.3 (I actually have some curl version 4 libraries installed, but those shouldn't matter now.) Then I start ghci and try to use curl: {{{ $ ghci 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> import Network.Curl Prelude Network.Curl> curlGet "http://weltraumschlangen.de/" [] Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package curl-1.3.8 ... can't load .so/.DLL for: libcurl.so (libcurl.so: cannot open shared object file: No such file or directory) Prelude Network.Curl> }}} So it seems it tries to load libcurl.so, which is contained in libcurl- dev, instead of libcurl.so.3. It's not working when compiling a file either: test.hs: {{{ import Network.Curl main = curlGet "http://weltraumschlangen.de/" [] }}} compiling: {{{ $ ghc --make test.hs [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... /usr/bin/ld: cannot find -lcurl collect2: error: ld returned 1 exit status }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 17:58:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 17:58:14 -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.ab11dbd7c04a473045e49a233337a3f7@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: ekmett Type: bug | Status: upstream Priority: normal | Milestone: Component: Core | Version: 7.6.2 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => upstream Comment: joeyhess: you might have more luck submitting a pull request to http://github.com/haskell/directory, and poking someone from the [http://www.haskell.org/haskellwiki/Core_Libraries_Committee corelibcom] to look at it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 18:00:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 18:00:45 -0000 Subject: [GHC] #9261: -S prints incorrect number of bound tasks In-Reply-To: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> References: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> Message-ID: <059.4168e5da5451ae1d1da26257ab56001c@haskell.org> #9261: -S prints incorrect number of bound tasks -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.8.2 System | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: Compiler => Runtime System * difficulty: Unknown => Easy (less than 1 hour) * keywords: => newcomer * owner: => simonmar Old description: > In `Stats.c` we have: > > {{{ > statsPrintf(" TASKS: %d (%d bound, %d peak workers (%d > total), using -N%d)\n", > taskCount, taskCount - workerCount, > peakWorkerCount, workerCount, > n_capabilities); > }}} > > but I think `taskCount - workerCount` must be wrong, because `taskCount` > is the _current_ number of tasks, while `workerAcount` is the _total_ > number of workers (accumulating). I think it should be: > > {{{ > statsPrintf(" TASKS: %d (%d bound, %d peak workers (%d > total), using -N%d)\n", > taskCount, taskCount - currentWorkerCount, > peakWorkerCount, workerCount, > n_capabilities); > }}} New description: In `rts/Stats.c` we have: {{{ statsPrintf(" TASKS: %d (%d bound, %d peak workers (%d total), using -N%d)\n", taskCount, taskCount - workerCount, peakWorkerCount, workerCount, n_capabilities); }}} but I think `taskCount - workerCount` must be wrong, because `taskCount` is the _current_ number of tasks, while `workerAcount` is the _total_ number of workers (accumulating). I think it should be: {{{ statsPrintf(" TASKS: %d (%d bound, %d peak workers (%d total), using -N%d)\n", taskCount, taskCount - currentWorkerCount, peakWorkerCount, workerCount, n_capabilities); }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 18:52:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 18:52:06 -0000 Subject: [GHC] #9260: Unnecessary error using GHC.TypeLits In-Reply-To: <051.9b98f43647329b740144a23edc96d4be@haskell.org> References: <051.9b98f43647329b740144a23edc96d4be@haskell.org> Message-ID: <066.53a708158080396b3ea92c5a9e1eac85@haskell.org> #9260: Unnecessary error using GHC.TypeLits -------------------------------------+------------------------------------- Reporter: | Owner: diatchki Iceland_jack | Status: new Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.8.2 Component: Compiler | Keywords: type lits, data Resolution: | kinds, error message Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Linux => Unknown/Multiple * milestone: => 7.10.1 Old description: > Compiling: > > {{{ > {-# LANGUAGE DataKinds, TypeOperators, GADTs #-} > > module Error where > > import GHC.TypeLits > > data Fin n where > Fzero :: Fin (n + 1) > Fsucc :: Fin n -> Fin (n + 1) > }}} > > gives a strange (unnecessary) error message claiming that `Fin 1` doesn't > match the expected type `Fin (0 + 1)`: > > {{{ > % ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.8.2 > % ghc -ignore-dot-ghci /tmp/Error.hs > [1 of 1] Compiling Error ( /tmp/Error.hs, /tmp/Error.o ) > > /tmp/Error.hs:12:8: > Couldn't match type ?0? with ?1? > Expected type: Fin 1 > Actual type: Fin (0 + 1) > In the expression: Fsucc Fzero > In an equation for ?test?: test = Fsucc Fzero > > /tmp/Error.hs:12:14: > Couldn't match type ?1? with ?0? > Expected type: Fin 0 > Actual type: Fin (0 + 1) > In the first argument of ?Fsucc?, namely ?Fzero? > In the expression: Fsucc Fzero > % > }}} New description: Compiling: {{{ {-# LANGUAGE DataKinds, TypeOperators, GADTs #-} module Error where import GHC.TypeLits data Fin n where Fzero :: Fin (n + 1) Fsucc :: Fin n -> Fin (n + 1) test :: Fin 1 test = Fsucc Fzero }}} gives a strange (unnecessary) error message claiming that `Fin 1` doesn't match the expected type `Fin (0 + 1)`: {{{ % ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 % ghc -ignore-dot-ghci /tmp/Error.hs [1 of 1] Compiling Error ( /tmp/Error.hs, /tmp/Error.o ) /tmp/Error.hs:12:8: Couldn't match type ?0? with ?1? Expected type: Fin 1 Actual type: Fin (0 + 1) In the expression: Fsucc Fzero In an equation for ?test?: test = Fsucc Fzero /tmp/Error.hs:12:14: Couldn't match type ?1? with ?0? Expected type: Fin 0 Actual type: Fin (0 + 1) In the first argument of ?Fsucc?, namely ?Fzero? In the expression: Fsucc Fzero % }}} -- Comment: GHC HEAD now gives the following error message for the program from the description: {{{ $ ghc-7.9.20141113 test.hs [1 of 1] Compiling Test ( test.hs, test.o ) test.hs:12:14: Couldn't match type ?n0 + 1? with ?0? The type variable ?n0? is ambiguous Expected type: Fin 0 Actual type: Fin (n0 + 1) In the first argument of ?Fsucc?, namely ?Fzero? In the expression: Fsucc Fzero }}} It looks like this bug got fixed, but I'm not 100% sure. A regression test is still missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 18:55:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 18:55:53 -0000 Subject: [GHC] #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" In-Reply-To: <045.33b56a4389644150958519a6a326156f@haskell.org> References: <045.33b56a4389644150958519a6a326156f@haskell.org> Message-ID: <060.6d3d4bfbea836e721928f4985dea755d@haskell.org> #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: #9360 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): I am getting the same panic for `ghci --show-options`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 18:57:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 18:57:20 -0000 Subject: [GHC] #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" In-Reply-To: <045.33b56a4389644150958519a6a326156f@haskell.org> References: <045.33b56a4389644150958519a6a326156f@haskell.org> Message-ID: <060.72439102ef459113fabbe8797eedc1b0@haskell.org> #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: #9360, #9259 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #9360 => #9360, #9259 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 18:59:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 18:59:29 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.07a4086b7d61201c48ff5c313a9abdf1@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D337 | -------------------------------------+------------------------------------- Comment (by thomie): I am currently running into `panic`s using `ghc-7.9.20141113 --interactive --show-options`, see #9799. I guess these will go away once Phab:D337 is landed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 19:07:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 19:07:17 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.bbc84395692b2565a9ef52adfa9109f5@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac | Owner: Dupree | Status: new Type: feature | Milestone: ? request | Version: 6.10.2 Priority: normal | Keywords: backpack Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9256 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9256 Comment: See #9256 for a recent proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 19:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 19:14:33 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.d7edb36547e253370679cc1d0cf322ae@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #9246 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * failure: None/Unknown => Runtime performance bug Comment: Adding 'newcomer' keyword by carter's suggestion in the description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 19:17:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 19:17:09 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.1d3250c148b617e41bca3cc3c8be19aa@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #9246 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: carter => Comment: Sorry carter, I'm trying to get this ticket to show up in [wiki:Newcomers]. Reclaim it if you want of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 20:11:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 20:11:59 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.e50fcfbd30a32fe4fb141d4872fb0bfc@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by thomie: Old description: > GHC already warns about variable shadowing: > > {{{ > timesTwoPlusOne x > = timesTwo x + 1 > where timesTwo x = x * 2 > > Warning: > This binding for `x' shadows the existing binding > bound at > }}} > > > However the similar warning doesn't happen for type variables. > > {{{ > tryMaybe :: IO a -> IO (Maybe a) > tryMaybe action = do > result <- (try action) :: IO (Either SomeException a) > return $ case result of > Left _ -> Nothing > Right v -> Just v > > Couldn't match type `a' with `a1' > `a' is a rigid type variable bound by > the type signature for tryMaybe :: IO a -> IO (Maybe a) > at types.hs::13 > `a1' is a rigid type variable bound by > an expression type signature: IO (Either SomeException a1) > at types.hs::15 > Expected type: IO a1 > Actual type: IO a > ... > }}} > > Here, I thought that the 'a' in the function's type declaration was the > same 'a' in the expression type declaration. However in Haskell 98, they > are completely different variables. > > Suggestion: if a type variable is renamed by the compiler due to a clash > with another type variable, issue a warning that the second shadows the > first, and give a hint about using -XScopedTypeVariables and forall. > > Alternative suggestion: if an error is displayed, where the error > contains a renamed type variable, issue a hint that the second shadows > the first, and give a hint about using -XScopedTypeVariables and forall. New description: GHC already warns about variable shadowing: {{{ $ cat test.hs module Test where timesTwoPlusOne x = timesTwo x + 1 where timesTwo x = x * 2 $ ghc -fwarn-name-shadowing test.hs ... Warning: This binding for `x' shadows the existing binding bound at }}} However the similar warning doesn't happen for type variables. {{{ $ cat T9244.hs module T9244 where import Control.Exception tryMaybe :: IO a -> IO (Maybe a) tryMaybe action = do result <- (try action) :: IO (Either SomeException a) return $ case result of Left _ -> Nothing Right v -> Just v $ ghc -fwarn-name-shadowing T9244.hs ... Couldn't match type `a' with `a1' `a' is a rigid type variable bound by the type signature for tryMaybe :: IO a -> IO (Maybe a) at types.hs::13 `a1' is a rigid type variable bound by an expression type signature: IO (Either SomeException a1) at types.hs::15 Expected type: IO a1 Actual type: IO a ... }}} Here, I thought that the 'a' in the function's type declaration was the same 'a' in the expression type declaration. However in Haskell 98, they are completely different variables. Suggestion: if a type variable is renamed by the compiler due to a clash with another type variable, issue a warning that the second shadows the first, and give a hint about using -XScopedTypeVariables and forall. Alternative suggestion: if an error is displayed, where the error contains a renamed type variable, issue a hint that the second shadows the first, and give a hint about using -XScopedTypeVariables and forall. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 20:25:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 20:25:23 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.9604eac20d0f95e2633c89400bdc5c1c@haskell.org> #9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: #7858, #9451 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by thomie: Old description: > Try the following program > {{{ > compareDouble :: Double -> Double -> Ordering > compareDouble x y = > case (isNaN x, isNaN y) of > (True, True) -> EQ > (True, False) -> LT > (False, True) -> GT > (False, False) -> > -- Make -0 less than 0 > case (x == 0, y == 0, isNegativeZero x, isNegativeZero y) of > (True, True, True, False) -> LT > (True, True, False, True) -> GT > _ -> x `compare` y > > main = do > let l = [-0, 0] > print [ (x, y, compareDouble x y) | x <- l, y <- l ] > }}} > > Compile and run with -O0 > {{{ > $ ghc -O0 D.hs > [1 of 1] Compiling Main ( D.hs, D.o ) > Linking D.exe ... > $ ./D > [(-0.0,-0.0,EQ),(-0.0,0.0,LT),(0.0,-0.0,GT),(0.0,0.0,EQ)] > }}} > This is the correct output. > > Compile and run with -O1 > {{{ > $ ghc -O1 D.hs > [1 of 1] Compiling Main ( D.hs, D.o ) > Linking D.exe ... > $ ./D > [(-0.0,-0.0,LT),(-0.0,0.0,LT),(0.0,-0.0,EQ),(0.0,0.0,EQ)] > }}} > This is wrong. > > Put a NOINLINE pragma on compareDouble: > {{{ > $ ghc -O1 D.hs > [1 of 1] Compiling Main ( D.hs, D.o ) > Linking D.exe ... > $ ./D > [(-0.0,-0.0,EQ),(-0.0,0.0,EQ),(0.0,-0.0,EQ),(0.0,0.0,EQ)] > }}} > This is wrong in a different way. New description: Try the following program {{{ compareDouble :: Double -> Double -> Ordering compareDouble x y = case (isNaN x, isNaN y) of (True, True) -> EQ (True, False) -> LT (False, True) -> GT (False, False) -> -- Make -0 less than 0 case (x == 0, y == 0, isNegativeZero x, isNegativeZero y) of (True, True, True, False) -> LT (True, True, False, True) -> GT _ -> x `compare` y main = do let l = [-0, 0] print [ (x, y, compareDouble x y) | x <- l, y <- l ] }}} Compile and run with -O0 {{{ $ ghc -O0 -fforce-recomp D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,LT),(0.0,-0.0,GT),(0.0,0.0,EQ)] }}} This is the correct output. Compile and run with -O1 {{{ $ ghc -O1 -fforce-recomp D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,LT),(-0.0,0.0,LT),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong. Put a NOINLINE pragma on compareDouble: {{{ $ ghc -O1 -fforce-recomp D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,EQ),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong in a different way. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 20:59:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 20:59:11 -0000 Subject: [GHC] #9229: Compiler memory use regression In-Reply-To: <047.2dfbe078c69c15d5f9a03a8fcfb51c79@haskell.org> References: <047.2dfbe078c69c15d5f9a03a8fcfb51c79@haskell.org> Message-ID: <062.290fd1d98d2d49961c4a4c01e20f5c59@haskell.org> #9229: Compiler memory use regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: #8852, #8980, Blocking: | #8941, 8960, #7898, #7068, #7944, Differential Revisions: | #5550, #8836 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * related: => #8852, #8980, #8941, 8960, #7898, #7068, #7944, #5550, #8836 Comment: Can you try to compile your module with either HEAD (the master branch) or the ghc-7.8 [wiki:Building/GettingTheSources branch]? Those branches contain the following bug fix, which should solve your problem: {{{ commit af4bc31c50c873344a2426d4be842f92edf17019 Author: Simon Peyton Jones Date: Mon Aug 25 12:28:44 2014 +0100 Do not duplicate call information in SpecConstr (Trac #8852) This long-standing and egregious bug meant that call information was being gratuitously copied, leading to an exponential blowup in the number of calls to be examined when function definitions are deeply nested. That is what has been causing the blowup in SpecConstr's running time, not (as I had previously supposed) generating very large code. See Note [spec_usg includes rhs_usg] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 21:03:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 21:03:08 -0000 Subject: [GHC] #9228: Internal compiler error with -O1 and -O2 In-Reply-To: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> References: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> Message-ID: <062.69ee6d78f7947883bc449469eb294501@haskell.org> #9228: Internal compiler error with -O1 and -O2 -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8892 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: A fix for #8892 has been merged into the 7.8 branch. Could you try again once 7.8.4 comes out? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 21:05:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 21:05:59 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.5c82e5f9ff11082de3aa3967e71b4546@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #9246 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): sure thing. I think the only newcomer friendly bit would be writing the branchless min/max for Word and Int and friends. its a bit more subtle for the floating point versions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 21:20:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 21:20:26 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.b2386b6110c60f0835bc160cf6ffcd8b@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: 9215 | Differential Revisions: Phab:D339 | -------------------------------------+------------------------------------- Changes (by thomie): * blocking: => 9215 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 21:43:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 21:43:02 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.73eb1c995ff6382abfb243f81ce38ec9@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Thank you for the report. You mention: "cpphs 1.18.5 yields the following warning". Can you supply the steps needed to reproduce this. Do you mean during the building/installation of cpphs, or when you run it some on some inputfile? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 14 22:14:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Nov 2014 22:14:02 -0000 Subject: [GHC] #9201: GHC unexpectedly refines explicit kind signatures In-Reply-To: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> References: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> Message-ID: <060.6fbcd4a662ec8327b3b56e3bd44c849c@haskell.org> #9201: GHC unexpectedly refines explicit kind signatures -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.10.1 Comment: With HEAD, the program from the description now shows the following error message: {{{ $ ghc-7.9.20141113 T9201.hs [1 of 1] Compiling T9201 ( T9201.hs, T9201.o ) T9201.hs:5:17: The first argument of ?f? should have kind ?x1?, but ?a? has kind ?y1? In the type ?d a (f a)? In the class declaration for ?MonoidalCCC? }}} I think this ticket can be closed, once a regression test is added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 02:13:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 02:13:45 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.905dd83a85f4ae3a54c860674b3e2481@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Ok, lets go through Array with a fine toothed comb: {{{ type role Array nominal representational type role IOArray nominal representational }}} That lets users case the element type in the array. This is safe because e.g. `instance IArray Array e` is fully polymorphic in `e` with no constraints. The index has to be nominal as it is tied to the semantics of the internal bounds, the underlying array size, etc. Users can coerce boxed arrays to change the element types. {{{ type role UArray nominal nominal type role IOUArray nominal nominal type role StorableArray nominal nominal }}} The index is nominal for the same reason as above, the element type is nominal because we'd otherwise silently be re-interpreting the bit representation of the underlying storables in the latter case, and the interpretation of the array size, etc. changes based on the same sort of information in `UArray` and `IOUArray`. {{{ type role STArray nominal nominal representational type role STUArray nominal nominal nominal }}} The region parameter is nominal lest users easily subvert `ST` safety, otherwise same as `Array` and `UArray` respectively. It turns out there isn't a lot of representational material here, just the element type in `Array`, `STArray` and `IOArray`. Every other role in the entire `array` package is necessarily `nominal`. Does that give enough to proceed? That should be every type used by the package, though, I think the bulk comes from `GHC.Arr`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 07:46:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 07:46:52 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.211e672d6ecb5726e5df0ff16212488a@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D476 Comment: It's up for review at Phab:D476! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 07:47:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 07:47:06 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.ccd97fbad960612095fc92717ec73726@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 11:22:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 11:22:27 -0000 Subject: [GHC] #9802: A ghci bug Message-ID: <046.a9f3dc24f27dcf2ded2d74b3283a1b51@haskell.org> #9802: A ghci bug -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: :force :type | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Prelude> let a = [1,2,3] (0.00 secs, 0 bytes) Prelude> :t a a :: Num t => [t] Prelude> :force a a = _ Prelude> a [1,2,3] (0.02 secs, 3580816 bytes) Prelude> :print a a = (_t1::Num t => [t]) Prelude> :t _t1 ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): tcTyVarDetails t{tv auB} [tv] 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 Nov 15 11:38:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 11:38:36 -0000 Subject: [GHC] #9802: A ghci bug In-Reply-To: <046.a9f3dc24f27dcf2ded2d74b3283a1b51@haskell.org> References: <046.a9f3dc24f27dcf2ded2d74b3283a1b51@haskell.org> Message-ID: <061.d96cbce248b70b5793db40e49a821444@haskell.org> #9802: A ghci bug -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: duplicate | Keywords: :force :type Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: #9046 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: None/Unknown => GHCi crash * resolution: => duplicate * related: => #9046 Old description: > Prelude> let a = [1,2,3] > (0.00 secs, 0 bytes) > Prelude> :t a > a :: Num t => [t] > Prelude> :force a > a = _ > Prelude> a > [1,2,3] > (0.02 secs, 3580816 bytes) > Prelude> :print a > a = (_t1::Num t => [t]) > Prelude> :t _t1 > ghc.exe: panic! (the 'impossible' happened) > (GHC version 7.8.3 for x86_64-unknown-mingw32): > tcTyVarDetails t{tv auB} [tv] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: {{{ #!haskell Prelude> let a = [1,2,3] (0.00 secs, 0 bytes) Prelude> :print a a = (_t1::Num t => [t]) Prelude> :t _t1 ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): tcTyVarDetails t{tv auB} [tv] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 12:37:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 12:37:04 -0000 Subject: [GHC] #9198: large performance regression in type checker speed in 7.8 In-Reply-To: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> References: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> Message-ID: <060.c5214177ddf2b86aba4570495f96e76e@haskell.org> #9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Old description: > it was recently demonstrated on the haskell-cafe mailing list that the > following code takes measurably longer to type check in GHC 7.8.2 than in > GHC 7.6. > > http://www.haskell.org/pipermail/haskell-cafe/2014-June/114562.html > > the program example is as follows > {{{ > begin cont = cont (return ()) > a m =cont (m >> putstrn "a") > end m = m > main = begin a a a a a a a a a a a a a a a a a end > > }}} > takes about a second to type check in ghc 7.8, and is "instant" in 7.6 () > > each additional a doubles the time to type check the program > > {{{ > main = begin a a a a a a a a a a a a a a a a a a a a a a a a end > }}} > > takes longer than I have the patience to wait :) (so more than 5 seconds) > > the author of the email notes that a related program > > {{{ > main = id id id id id id id id id id id > id id id id id id id id id id id (return ()) > }}} > has the exponential complexity in both 7.8.2 and 7.6.2 > > This It could very well be that some of the type checker changes between > 7.8 and 7.6 enlarged the space of programs that trip up exponential worst > case behavior, but one way or another understanding *why* this happened New description: it was recently demonstrated on the haskell-cafe mailing list that the following code takes measurably longer to type check in GHC 7.8.2 than in GHC 7.6. http://www.haskell.org/pipermail/haskell-cafe/2014-June/114562.html the program example is as follows {{{ begin :: Monad m => (m () -> t) -> t begin cont = cont (return ()) a :: IO a -> (IO () -> t) -> t a m cont = cont (m >> putStrLn "a") end :: t -> t end m = m main = begin a a a a a a a a a a a a a a a a a a end }}} takes about a second to type check in ghc 7.8, and is "instant" in 7.6 () each additional a doubles the time to type check the program {{{ main = begin a a a a a a a a a a a a a a a a a a a a a a a a end }}} takes longer than I have the patience to wait :) (so more than 5 seconds) the author of the email notes that a related program {{{ main = id id id id id id id id id id id id id id id id id id id id id id (return ()) }}} has the exponential complexity in both 7.8.2 and 7.6.2 This It could very well be that some of the type checker changes between 7.8 and 7.6 enlarged the space of programs that trip up exponential worst case behavior, but one way or another understanding *why* this happened -- Comment (by thomie): For what it's worth: crude timing results for the example from the description with 18 `a`'s: ||= GHC =||= Time =|| ||= 7.4.2 =|| 2.2s || ||= 7.6.3 =|| 2.2s || ||= 7.8.3 =|| 3.4s || ||= 7.9.20141113 =|| 3.8s || Command: `time ghc -c -fforce-recomp test.hs` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 12:46:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 12:46:52 -0000 Subject: [GHC] #9197: FFI types should be usable in foreign import decls without revealing representations In-Reply-To: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> References: <045.1e66fe66ff436f9c3e1f990da91bd5b9@haskell.org> Message-ID: <060.602d4baf883a4bf33713d921e6ce40ea@haskell.org> #9197: FFI types should be usable in foreign import decls without revealing representations -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (FFI) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 12:50:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 12:50:13 -0000 Subject: [GHC] #9192: Add sameByteArray# In-Reply-To: <044.4adc5b0f7cf12ed14c392d7866ef0f7f@haskell.org> References: <044.4adc5b0f7cf12ed14c392d7866ef0f7f@haskell.org> Message-ID: <059.fd7d4e545b34d98301a4bbc79b799537@haskell.org> #9192: Add sameByteArray# -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 12:52:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 12:52:47 -0000 Subject: [GHC] #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknown archs In-Reply-To: <050.ec9d0ec38ab57c70c2fd6acc66f09adc@haskell.org> References: <050.ec9d0ec38ab57c70c2fd6acc66f09adc@haskell.org> Message-ID: <065.6f5c58ab7fdc014ef2d02916caaf26ed@haskell.org> #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknown archs -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen juhpetersen | Status: patch Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch Comment: LGTM -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 13:23:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 13:23:06 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.f6c6d1342d467dfe11ff1d5430cbc470@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by asr): You can reproduce the issue by installing Agda (sorry I know this is not a simple package). Note that Agda uses cpphs as the default C preprocessor. {{{cabal install Agda-2.4.2.1}}} {{{...}}} {{{Preprocessing library Agda-2.4.2.1...}}} {{{Warning: trailing characters after #if directive in file /usr/local/stow/ghc-7.8.3-bin/lib/ghc-7.8.3/include/ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 15:19:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 15:19:40 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.8ddc98a8b3fe2d8a0fd623bc9955edbe@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks, Edward; that's beautifully concrete. Will implement in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 21:13:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 21:13:34 -0000 Subject: [GHC] #9800: Panic when building HEAD with BuildFlavour=quickest: "Can't use Integer in integer-*" In-Reply-To: <045.7ea66f0ee84308012af7c56c8492b8b1@haskell.org> References: <045.7ea66f0ee84308012af7c56c8492b8b1@haskell.org> Message-ID: <060.56e3c1e6840626bbe134eedd74820a87@haskell.org> #9800: Panic when building HEAD with BuildFlavour=quickest: "Can't use Integer in integer-*" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * version: 7.8.3 => 7.9 * resolution: => fixed * milestone: => 7.10.1 Comment: Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 21:27:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 21:27:57 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour In-Reply-To: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> References: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> Message-ID: <066.d03c817c478dffaae55e8ecacbd9958c@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour -------------------------------------+------------------------------------- Reporter: | Owner: ulysses4ever | Status: closed Type: bug | Milestone: Priority: normal | Version: Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: worksforme | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: I just did a succesful build with BuildFlavour=quickest. DPH is no longer built by default, see: "[https://www.haskell.org/pipermail/ghc- devs/2014-August/006189.html I'm going to disable DPH until someone starts maintaining it]". Since then, these [https://phabricator.haskell.org/D302 commits] were made to fix the DPH build. Please open a new ticket if anyone runs into problems building dph in the future. {{{ commit 27f7552745fa320e72096b30b08558b7a275bbcc Author: Geoffrey Mainland Date: Thu Oct 2 17:39:34 2014 -0400 Make Applicative-Monad fixes for tests. commit 710bc8d77be454243ae8de2a1fb9070b72b525c4 Author: Geoffrey Mainland Date: Wed Aug 27 22:33:44 2014 -0400 Update primitive, vector, and dph submodules. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 22:08:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 22:08:21 -0000 Subject: [GHC] #9803: Poor error message for unbound variable in pattern synonym Message-ID: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> #9803: Poor error message for unbound variable in pattern synonym -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I say {{{ pattern OneElt = [x] }}} I get {{{ Right-hand side of bidirectional pattern synonym cannot be used as an expression [x] }}} I have two complaints with this error message: 1. It's very unclear what's actually wrong with the pattern -- `[x]` looks like a perfectly fine expression, until I realize that `x` is unbound. 2. The herald of the error is more than 80 characters (if you count the indentation) and wraps on my 80-character terminal. GHC tends to avoid this elsewhere, and so the wrapping is suboptimal. I would easily say that issue (1) is more important than issue (2). Perhaps this would be better: {{{ Variable `x' is unbound in the bidirectional pattern synonym `OneElt': [x] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 15 23:08:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Nov 2014 23:08:32 -0000 Subject: [GHC] #9700: Support C structures in Haskell FFI In-Reply-To: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> References: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> Message-ID: <059.0544ceb1f7bafb3c28f845f81fc71a2e@haskell.org> #9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D252 | -------------------------------------+------------------------------------- Changes (by Yuras): * owner: Yuras => Comment: There is no chance that I'll catch 7.10 release, I'm stuck in type checker. I'm unassigning the ticket in case someone else wants to try. Probably someone with better knowledges of ghc internals will be able to finish implementation. Anyway, I have ~1 year till 7.12 to find my way into the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 04:34:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 04:34:20 -0000 Subject: [GHC] #9120: Cache intermediate powers In-Reply-To: <049.1ee5b6115869efb06c318270302523f2@haskell.org> References: <049.1ee5b6115869efb06c318270302523f2@haskell.org> Message-ID: <064.e1209329ed851b83b83598f7c5dbea5e@haskell.org> #9120: Cache intermediate powers -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 06:35:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 06:35:10 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken In-Reply-To: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> References: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> Message-ID: <062.71f5c62bdbe019934151db86956f29d4@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 9421 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by codygman): Just wanted to say that I'm also affected by this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 10:22:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 10:22:43 -0000 Subject: [GHC] #9120: Cache intermediate powers In-Reply-To: <049.1ee5b6115869efb06c318270302523f2@haskell.org> References: <049.1ee5b6115869efb06c318270302523f2@haskell.org> Message-ID: <064.c4e6311646cb7780434a46be75f9b484@haskell.org> #9120: Cache intermediate powers -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): This seems pretty straight forward and the code looks correct to me. The main cost being borne right now is that rather than being `O(n)` to compute the array it is `O(n log n)`. With `n` bounded above by `1100`, and it only hitting you while you force these constants the first time it'll be hard to find a benchmark materially affected, as they 'warm up' more or less instantly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 14:02:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 14:02:45 -0000 Subject: [GHC] #8798: Missing symbols with -fprof-auto-calls In-Reply-To: <044.ec0f35676741d6c60bda2b0c22aed413@haskell.org> References: <044.ec0f35676741d6c60bda2b0c22aed413@haskell.org> Message-ID: <059.2b00277bf130a5f9aac2188cece21a59@haskell.org> #8798: Missing symbols with -fprof-auto-calls -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: edsko: please re-open if you can reproduce with 7.8 or later, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 14:34:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 14:34:47 -0000 Subject: [GHC] #8780: abs for IEEE floating point is slightly wrong. In-Reply-To: <047.7d758a25f9194c7d9c9382206575054a@haskell.org> References: <047.7d758a25f9194c7d9c9382206575054a@haskell.org> Message-ID: <062.bd36b6438802b81a4aab7e9563700c08@haskell.org> #8780: abs for IEEE floating point is slightly wrong. -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * failure: None/Unknown => Incorrect result at runtime Comment: I cannot reproduce your findings. Can you try again, specifying your GHC version, OS and architecture. Thanks. {{{ $ uname -op x86_64 GNU/Linux $ ghc-7.6.3 --interactive 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> abs(-0) 0 Prelude> signum(-0) == 0 True Prelude> let x = -0 in abs x * signum x == x True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 14:44:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 14:44:59 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.732585478b117050eb24ac81f18bf06f@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: #5928, #8668, Blocking: | #8099 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: 5928, 8668, 8099 => #5928, #8668, #8099 Comment: crockeaa: this seems to have been overlooked, maybe try asking on the ghc- devs mailinglist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 14:46:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 14:46:29 -0000 Subject: [GHC] #8772: ghci should save history more often In-Reply-To: <046.7de96bdd9c1f26a5cddbf4d5489fb344@haskell.org> References: <046.7de96bdd9c1f26a5cddbf4d5489fb344@haskell.org> Message-ID: <061.cae5806c7a76db59373cb811cb7cc412@haskell.org> #8772: ghci should save history more often -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: feature | Status: upstream request | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 14:56:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 14:56:08 -0000 Subject: [GHC] #9796: Implement amap/coerce rule for `Array` In-Reply-To: <045.6e18c11ce0de8ebcd631eb7d710d6e30@haskell.org> References: <045.6e18c11ce0de8ebcd631eb7d710d6e30@haskell.org> Message-ID: <060.f7cc2f0a63386239c1fc3ce273a93886@haskell.org> #9796: Implement amap/coerce rule for `Array` -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #8767 Test Case: | Blocking: | Differential Revisions: Phab:D471 | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8767 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 15:02:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 15:02:55 -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.460759dc74bd2723e0e8503bff0266a7@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8718 Type of failure: | Related Tickets: #2110 None/Unknown | Test Case: | tests/simplCore/should_run/T2110.hs| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: dfeuer, core-libraries-committee@? (added) Comment: {{{ commit 603b7be7bd3abaf0e2c210e8d9015b1d613b4715 Author: David Feuer Date: Thu Nov 13 21:12:05 2014 +0100 Implement amap/coerce for Array (re #9796) Implement an `amap`/`coerce` rule in `GHC.Arr` to match the `map`/`coerce` rule in GHC.Base. In order to do so, delay inlining `amap` until phase 1. To prevent the inlining delay from causing major inefficiencies due to missed list fusion, rewrite `amap` to avoid relying on list fusion. This has the extra benefit of reducing the size of the compiled amap code by skipping the impossible case of an array with a negative size. Reviewed By: nomeata Differential Revision: https://phabricator.haskell.org/D471 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 15:11:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 15:11:17 -0000 Subject: [GHC] #9804: Layering: Suspicious dependency from Parser to TcEvidence Message-ID: <047.cfa5b05c6b1aa1694169baaaf1f8a060@haskell.org> #9804: Layering: Suspicious dependency from Parser to TcEvidence -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There is an import from Parser to TcEvidence module. Why does the parser need to know about type checking? The parser should produce an AST and through the AST (and global modules) be isolated from the rest of the compiler pipeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 15:14:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 15:14:18 -0000 Subject: [GHC] #9804: Layering: Suspicious dependency from Parser to TcEvidence In-Reply-To: <047.cfa5b05c6b1aa1694169baaaf1f8a060@haskell.org> References: <047.cfa5b05c6b1aa1694169baaaf1f8a060@haskell.org> Message-ID: <062.e1d6179801c76d2176566bd315ea50c0@haskell.org> #9804: Layering: Suspicious dependency from Parser to TcEvidence -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): Along the same lines, why does HsSyn modules needs to import TcEvidence? The AST is a common currency across the pipeline and should be isolated as much as possible from the rest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 15:49:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 15:49: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.bd7d6c3f25d7a5bc6eecb6a8cafc5efb@haskell.org> #8767: Add rules involving `coerce` to the libraries -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8718 Type of failure: | Related Tickets: #2110 None/Unknown | Test Case: | tests/simplCore/should_run/T2110.hs| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:21 dmcclean]: > One possible thing would be to have an {-# UNLAWFUL #-} pragma, and when you are magically generating instances you branch three ways instead of 2. (Possibly such a pragma could allow more aggressive optimizations in other cases too, with an opt out for 'criminals'?) I think it would make more sense to track `Functor` instances believed to be (sufficiently) lawful. A functor could be labeled `{-# LAWFUL #-}` in either `Unsafe` or `Trustworthy` modules, and any ''derived'' `Functor` instance without a `Functor` context could be treated as lawful as well. A functor labeled as `{-# LAWFUL #-}` could of course be lawful only up to some isomorphism; the pragma would declare that the instance won't break in any important way if the compiler relies on the functor laws. A similar mechanism could presumably be applied to other classes as well. Interaction with extreme polymorphism: to really take advantage, you'd presumably need to be able to express lawfulness in a context. So you'd need to be able to write something like {{{#!hs g :: ({-# LAWFUL #-} Functor f) => ... }}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 17:55:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 17:55:57 -0000 Subject: [GHC] #8756: Test case concurrent/should_run/T5611 fails on Mac In-Reply-To: <047.9ca2116412c11f6c3e9b82c18e16195a@haskell.org> References: <047.9ca2116412c11f6c3e9b82c18e16195a@haskell.org> Message-ID: <062.affb472e70e3edf73bdc21eb58052464@haskell.org> #8756: Test case concurrent/should_run/T5611 fails on Mac -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9389 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * component: Compiler => Test Suite * related: => #9389 Comment: Let's combine all these (full) testsuite failures for Mac in #9389. There's too many to have individual tickets for all of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 17:56:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 17:56:48 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.25a12fddaf2bc9bbe0847f06ba13d041@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------ Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9286,#8756 Differential Revisions: | -------------------------------------+------------------------------------ Changes (by thomie): * related: #9286 => #9286,#8756 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 18:44:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 18:44:38 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.b73f3bce7a967a650ba1576cb0b1ae10@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #8740 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8740 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 18:44:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 18:44:57 -0000 Subject: [GHC] #9143: feature request: way to set actual program argv In-Reply-To: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> References: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> Message-ID: <062.c9f9e51c86d766febebee69c056cc95f@haskell.org> #9143: feature request: way to set actual program argv -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: simonmar Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Moderate (less Operating System: Linux | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by joeyhess): prctl can be used to set the name of a thread. This does not change the process name as displayed by ps. (The stackoverflow article is apparently wrong or out of date or something -- try the sample program there and you'll see it does not change the display in ps, although /proc/pid/task/tid/comm will be changed.) At least on linux when using libbsd's setproctitle, it requires setproctitle_init to first be called and passed the original argv. The libbsd-ctor arranges for this to be done at program startup. So, I was able to get that to work by passing these options to ghc: -lbsd-ctor -optl-u -optllibbsd_init_func -lbsd On linux, using a not very widely used libbsd, and needing linker options to make it work, seems like a rather long way around.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 18:45:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 18:45:06 -0000 Subject: [GHC] #8740: Deriving instance conditionally compiles In-Reply-To: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> References: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> Message-ID: <065.fb87e5adff5bdc73ee9ef3a1267c6426@haskell.org> #8740: Deriving instance conditionally compiles -------------------------------------+------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8128 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * component: Compiler => Compiler (Type checker) * related: => #8128 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 20:07:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 20:07:52 -0000 Subject: [GHC] #9143: feature request: way to set actual program argv In-Reply-To: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> References: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> Message-ID: <062.56df85b168fdc98249344b6dc3b2a748@haskell.org> #9143: feature request: way to set actual program argv -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: Linux | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: simonmar => * status: closed => new * resolution: wontfix => Comment: Or maybe that stackoverflow answer is not out of date, but it's just only one half of the story? I added this comment: "This seems to only change the name in the output of 'ps -A', 'ps -a' 'ps -d', 'ps -e' and maybe others, whereas 'ps a', 'ps -ef', 'ps f' and probably others still show the original command line arguments." Changing argv[0] would then be the other half of the story, like you suggested in the description. This C example shows "othername" when using 'ps -ef', but not when doing 'ps -e'. In `top` you can toggle between the two by hitting the `c` key. {{{ #include #include int main(int argc, char** argv) { strcpy(argv[0],"othername"); sleep(1000); return 0; } }}} So doing both would be needed: change `argv` and call `prctl`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 20:39:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 20:39:45 -0000 Subject: [GHC] #8731: long compilation time for module with large data type and partial record selectors In-Reply-To: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> References: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> Message-ID: <060.70aa5e932c30222ffccb95090ecfd238@haskell.org> #8731: long compilation time for module with large data type and partial record selectors -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Timing results for the example from comment:1. ||= GHC || -O1 || -O2 || ||= 7.4.2 || 4.9s || 16s || ||= 7.6.3 || 5.0s || 15s || ||= 7.8.3 || 4.4s || 12s || ||= 7.9.20141113 || 4.4s || 14s || Command: `time ghc -fforce-recomp -O Constant.hs` Compilation takes only about 1 second, with either `-O1` or `-O2`, when I remove the `deriving (Eq, Ord, Read, Show)` clause from `data Constant`. The resulting object file also reduces in size from 1mb to 100kb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 21:34:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 21:34:10 -0000 Subject: [GHC] #9700: Support C structures in Haskell FFI In-Reply-To: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> References: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> Message-ID: <059.511a4ebd257d7a8018a5d112d6bad7fd@haskell.org> #9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D252 | -------------------------------------+------------------------------------- Comment (by svenpanne): Hmmm, I think the wiki page is confusing C types and Haskell types: * If one wants to bind to a C structure containing int/char/float/..., one has to use CInt/CChar/CFloat/... on the Haskell side. * If one wants to access Haskell stuff containing Int/Char/Float, one has to use HsInt/HsChar/HsFloat/... on the C side. Any kind of structure marshaling can't change anything about that, there's no portable correspondence between the types in both worlds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 21:38:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 21:38:45 -0000 Subject: [GHC] #8730: Invalid Unicode Codepoints in Char In-Reply-To: <047.d29dc672b6ffe33afb3c95f4df30833b@haskell.org> References: <047.d29dc672b6ffe33afb3c95f4df30833b@haskell.org> Message-ID: <062.5e3054cc6b3a23372af3595d307189ed@haskell.org> #8730: Invalid Unicode Codepoints in Char -------------------------------------+------------------------------------- Reporter: mdmenzel | Owner: ekmett Type: bug | Status: new Priority: low | Milestone: Component: Core | Version: 7.6.3 Libraries | Keywords: unicode Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: batterseapower, core-libraries-committee@? (added) * owner: => ekmett * component: Compiler => Core Libraries Comment: Thank you for the report. I am just adding some references. {{{ Prelude Data.Char> all ((==) Surrogate . generalCategory) ['\xdc80' .. '\xdfff'] True }}} * http://www.unicode.org/versions/Unicode7.0.0/ch23.pdf * http://tools.ietf.org/html/rfc3629 * http://en.wikipedia.org/wiki/UTF-8#Invalid_code_points: >According to the UTF-8 definition (RFC 3629) the high and low surrogate halves used by UTF-16 (U+D800 through U+DFFF) are not legal Unicode values, and their UTF-8 encoding should be treated as an invalid byte sequence. >Whether an actual application should do this is debatable, as it makes it impossible to store invalid UTF-16 (that is, UTF-16 with unpaired surrogate halves) in a UTF-8 string. This is necessary to store unchecked UTF-16 such as Windows filenames as UTF-8. It is also incompatible with CESU encoding (described below). In commit dc58b7398910a433259a6c0f58a0d05a48555191: {{{ Author: Max Bolingbroke <> Date: Sat May 14 22:50:46 2011 +0100 Big patch to improve Unicode support in GHC. Validated on OS X and Windows, this patch series fixes #5061, #1414, #3309, #3308, #3307, #4006 and #4855. }}} This commit adds checks like `... if isSurrogate c then done InvalidSequence ir ow else do ...` to GHC/IO/Encoding/UTF{8|16|32}.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 16 22:47:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Nov 2014 22:47:20 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.56bf675015a533a093c91e2b74710348@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D452 | -------------------------------------+------------------------------------- Comment (by rodlogic): Replying to [comment:2 rodlogic]: > I have a fix for this in https://phabricator.haskell.org/D452. However, I just realized that I forgot to create a specific option for this warning. But does this even need an option?? I did spend some time trying to make the following case work, which is a similar to the one described in the summary: {{{ import Data.Maybe -- * whatever import Data.Functor }}} Parsing the above with the haddock flag turned on will lead to the following error: {{{ a1.hs:3:1: parse error on input ?import? }}} When the haddock flag is turned on, the comment line is scanned as a ITdocSection token instead of a ITlineComment. However, instead of being ignored by the lexer an ITdocSection is returned to the parser as a token. The problem is that the import rules are not expecting any documentation tokens and the parsing fails. So fixing this requires modifying the {{{import}}} rule to be similar to how the {{{expor}}}t rules are implemented, i.e. explicitly taking into account the different haddock tokens. I just find it a bit strange that both the parser and lexer need to know about haddock comments. Any changes to haddock (e.g. introducing a new haddock comment type) would require changing the GHC's lexer and the parser! I was expecting to see the lexer to generate a generic single or multiline comment token that would be incorporated into the AST by the parser, and then haddock would be able to further process these comments based on it's own rules. Later this week I will see if I can address the summary case since it may be simpler, but it seems that it would be a good idea to generalize the parsing of comments and make GHC's parser/lexer a bit more independent of Haddock (in a different ticket). Alanz changes to the AST may be a good first step here and I will take a closer look there too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 00:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 00:31:59 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.23a9e14bcaac579040144d61ae80c214@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: TH_Depends | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by refold): Docstring for `addDependentFile` should say that it looks at file content, not timestamp (unlike `ghc --make`). I just wasted some time wondering why `touch some/dependent/file && ghc --make` doesn't cause recompilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 00:51:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 00:51:33 -0000 Subject: [GHC] #8721: Testsuite not reporting errors for DYN way on OS X In-Reply-To: <046.8af9e017e06f897fefadc3e624641754@haskell.org> References: <046.8af9e017e06f897fefadc3e624641754@haskell.org> Message-ID: <061.d09563cbf047b8464aef22498ddb6e81@haskell.org> #8721: Testsuite not reporting errors for DYN way on OS X -------------------------------------+------------------------------------ Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Comment (by thomie): > Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8. darchon: * Does that mean we can refrain from setting `DYLD_LIBRARY_PATH`, and the tests will still work? * And if, after doing so, there ever was a regression with respect to that commit, it would then actually get caught? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 00:53:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 00:53:31 -0000 Subject: [GHC] #8716: improve AMP join warning In-Reply-To: <045.d09131c80ac8da9f457a269f3c27dc3f@haskell.org> References: <045.d09131c80ac8da9f457a269f3c27dc3f@haskell.org> Message-ID: <060.4f2edf1c8296cb5d12ddfaabc07e2202@haskell.org> #8716: improve AMP join warning -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: All AMP warnings have been removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 00:55:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 00:55:24 -0000 Subject: [GHC] #2526: Warn about missing signatures only for exported functions In-Reply-To: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> References: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> Message-ID: <069.06e6652806b496764524e2b24a43e907@haskell.org> #2526: Warn about missing signatures only for exported functions -------------------------------------+------------------------------------- Reporter: | Owner: gridaphobe fergushenderson | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.8.3 Priority: lowest | Keywords: newcomer Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * owner: => gridaphobe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 01:20:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 01:20:02 -0000 Subject: [GHC] #8689: confusing comment in compiler/main/SysTools.lhs In-Reply-To: <045.cb716bf4926e5132d3b596b76f597be0@haskell.org> References: <045.cb716bf4926e5132d3b596b76f597be0@haskell.org> Message-ID: <060.ba3823a0b8f28a2cdef15e2249282dd8@haskell.org> #8689: confusing comment in compiler/main/SysTools.lhs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): That comment was added in 16d5d1c75c999677783c9c1bda519540fa9a6e58, possibly copied from somewhere else. 'Hans' must be referring to Hans-Wolfgang Loidl (hwloidl), who added 7 commits to ghc around that time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 01:27:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 01:27:55 -0000 Subject: [GHC] #8688: internal error: stg_ap_p_ret In-Reply-To: <048.a449a45e89bcdd1d34e6aa01b703899b@haskell.org> References: <048.a449a45e89bcdd1d34e6aa01b703899b@haskell.org> Message-ID: <063.a03307a1a470041a3479de586cef52e2@haskell.org> #8688: internal error: stg_ap_p_ret -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: massysett: please re-open if you run into this problem again, ideally with a description on how to reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 01:36:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 01:36:21 -0000 Subject: [GHC] #8685: -split-objs doesn't work for executables In-Reply-To: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> References: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> Message-ID: <060.52bfd4295e536b9e37bd79bfc016b7e9@haskell.org> #8685: -split-objs doesn't work for executables -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request Comment: It is mentioned in the user's guide: https://www.haskell.org/ghc/docs/latest/html/users_guide/flag- reference.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 01:39:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 01:39:21 -0000 Subject: [GHC] #8685: -split-objs doesn't work for executables In-Reply-To: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> References: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> Message-ID: <060.51996d098d43370cb512e544a82c9719@haskell.org> #8685: -split-objs doesn't work for executables -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by refold: Old description: > While investigating [this bug > report](https://github.com/haskell/cabal/issues/1611), I've noticed that > the `-split-objs` option only works for libraries, but not for > executables. That is, unlike in the case of libraries, the driver feeds > only `A.o B.o ...` files to the linker instead of `A_split_0.o > A_split_1.o ... B_split_0.o B_split_1.o ...`. It'd be nice if `-split- > objs` could be changed to also work on executables. New description: While investigating [https://github.com/haskell/cabal/issues/1611 this bug report], I've noticed that the `-split-objs` option only works for libraries, but not for executables. That is, unlike in the case of libraries, the driver feeds only `A.o B.o ...` files to the linker instead of `A_split_0.o A_split_1.o ... B_split_0.o B_split_1.o ...`. It'd be nice if `-split-objs` could be changed to also work on executables. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 01:42:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 01:42:05 -0000 Subject: [GHC] #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction In-Reply-To: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> References: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> Message-ID: <063.0d5a9edadff3127a6bd95828a0b18201@haskell.org> #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: > As ezyang said, this is the expected behavior. jberryman: if you're still interested, feel free to open a new ticket for that `nondeterministic orElse`. Please refer back to this ticket if you do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 01:50:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 01:50:07 -0000 Subject: [GHC] #8671: Rebindable syntax creates bogus warning In-Reply-To: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> References: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> Message-ID: <065.7bfc9cf50a20918a7dcbe6bc281250be@haskell.org> #8671: Rebindable syntax creates bogus warning -------------------------------------+------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Incorrect | warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 02:11:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 02:11:01 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.41d5bd03b524161d061aa6f6fcc707e4@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug Comment: crockeea: do you get the same results with 7.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 02:23:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 02:23:42 -0000 Subject: [GHC] #8665: RELEASE_LOCK: I do not own this lock In-Reply-To: <044.046fcc75b25880b48183ae432cde742a@haskell.org> References: <044.046fcc75b25880b48183ae432cde742a@haskell.org> Message-ID: <059.1b02235bb339a1aafaf8ec0c84dbe678@haskell.org> #8665: RELEASE_LOCK: I do not own this lock -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * os: MacOS X => Unknown/Multiple * status: new => infoneeded * component: Compiler => Runtime System * milestone: ? => Comment: guest: thank you for reporting. I would change this to 'status=infoneeded' normally, but without anyone to contact, and no way to reproduce, there's really not much we can do here. Please reopen if you run into this problem again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 02:24:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 02:24:00 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup Message-ID: <045.621217884d547d5010b211251c8e4ea4@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) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, type class instance resolution is performed by doing a map lookup by type class, and then linearly matching against every instance. This is not great, and for a while, simonpj has been keen on using the TrieMap data structure in GHC, which has been previously used to implement a map from CoreExprs to various things (e.g. for CSE). What makes this a little tricky is that instance lookup isn't intended to be an exact match: we should unify so-called template variables and provide a substitution; furthermore, there may be multiple matches. After some prototyping, I think we should be able to make this work. The primary refactoring we have to do is *maintain the key associated with an entry in a TrieMap*. Unlike the current uses of TrieMaps, where it's acceptable to lose the underlying key associated with an entry in the TrieMap, we need to know the key when doing unification, because it may be reported in the substitution. There are a few knock-on effects of this: * We should add a method `foldWithKeyTM :: (Key m -> a -> b -> b) -> m a -> b -> b` to the `TrieMap` type class. * We need a variant of `UniqFM` which tracks the original key that was used. I propose we name it `UniqKM` (unique key map). A number of implementations of `TrieMap` need to be adjusted to use this instead of `UniqFM`. * Why can't we just represent keyed TrieMaps as `TypeMap (Type, a)`? It might be possible. An insurmountable difficulty would be if we need to know the partial key PRIOR to having finished traversing the TrieMap; however, for the parts of the unification algorithm I've implemented, this does not seem to be the case. The primary actual difficulty is that `Type` uses a named representation, whereas `TypeMap` keys are on-the-fly deBruijn numbered. There would at least be some annoying fiddliness. * Reversing the deBruijn numbered key into a `Type` is a bit goofy. Essentially, you need the reverse of the current `CmEnv`: a mapping from de Bruijn levels to the `Var` you've decided to allocate. (I've called this `CfEnv` in my prototype) * When we represent a TrieMap binder, we have to put the binder map on the OUTSIDE, as opposed to the inside as it is currently. Otherwise, we can't update the `CfEnv` with the new mapping before making the recursive call to fold-with-key. I'll attach the standalone Haskell file I used to prototype this, wherein I copy-pasted a lot of Haskell from GHC's source and implemented fuzzy map on a simplified version of `Type`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 02:26:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 02:26:19 -0000 Subject: [GHC] #8664: libffi does not recognize AArch64 (ARM64) In-Reply-To: <046.f6fd599894b770d8f463eddb4be500e6@haskell.org> References: <046.f6fd599894b770d8f463eddb4be500e6@haskell.org> Message-ID: <061.7c0ae49f3e436a30f8b78ab61b8ed243@haskell.org> #8664: libffi does not recognize AArch64 (ARM64) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core | Version: 7.7 Libraries | Keywords: Resolution: duplicate | Architecture: arm Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: #8701 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => duplicate * related: => #8701 Comment: HEAD has been updated to libffi 3.1 in #8701. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 02:51:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 02:51:45 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.b50fe548567b3e968b82b85c666de8e3@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: TH_Depends | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by GregWeber): I added the documentation: https://phabricator.haskell.org/D481 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 02:56:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 02:56:11 -0000 Subject: [GHC] #8650: Unexpected behaviour of import ccall "header.h function" In-Reply-To: <042.6c752e15c4b7ff5eb43bc6ab27a23ec9@haskell.org> References: <042.6c752e15c4b7ff5eb43bc6ab27a23ec9@haskell.org> Message-ID: <057.f22fba9a2b426dd96806ea05eca2a190@haskell.org> #8650: Unexpected behaviour of import ccall "header.h function" -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): From Section 8.5.1 of the report (emphasis mine): >The ''optional'' filename `chname` specifies a C header file, where the intended meaning is that the header file declares the C entity identified by `cid`. From the GHC [https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/ffi- ghc.html#glasgow-foreign-headers user's guide]: > C functions are normally declared using prototypes in a C header file. Earlier versions of GHC (6.8.3 and earlier) #included the header file in the C source file generated from the Haskell code, and the C compiler could therefore check that the C function being called via the FFI was being called at the right type. > GHC no longer includes external header files when compiling via C, so this checking is not performed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 03:11:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 03:11:40 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.80b47f0b29b0a20c79bde205cfa99c77@haskell.org> #8647: Reduce allocations in `integer-gmp` -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.3 Libraries | Keywords: integer-gmp Resolution: fixed | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #8638 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => fixed Comment: Since we're using `integer-gmp2` now (#9281), I'm assuming this can be closed. Please re-open if I'm mistaken, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 05:32:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 05:32:50 -0000 Subject: [GHC] #8650: Unexpected behaviour of import ccall "header.h function" In-Reply-To: <042.6c752e15c4b7ff5eb43bc6ab27a23ec9@haskell.org> References: <042.6c752e15c4b7ff5eb43bc6ab27a23ec9@haskell.org> Message-ID: <057.311262a1031f93cec9ac54b3bf6b8a32@haskell.org> #8650: Unexpected behaviour of import ccall "header.h function" -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): huh, so ghc no longer provides that validation because we no longer do f-via-c by default? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 09:09:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 09:09:16 -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.63cb8cd3fa2c4e85cb183cd9a7b0a09a@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 | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Great stuff. * I suggest making this a new data type, rather than simply replacing `TrieMap`. The latter is simple, uniform, and efficient. Let's not clutter it up! * But perhaps `TrieMap` itself can be modestly improved, by giving access to the key. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 09:53:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 09:53:35 -0000 Subject: [GHC] #9804: Layering: Suspicious dependency from Parser to TcEvidence In-Reply-To: <047.cfa5b05c6b1aa1694169baaaf1f8a060@haskell.org> References: <047.cfa5b05c6b1aa1694169baaaf1f8a060@haskell.org> Message-ID: <062.5d89a1dca7d5047756ef004cdd2ab90d@haskell.org> #9804: Layering: Suspicious dependency from Parser to TcEvidence -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Fair point, but there is a good reason for this. The same `HsSyn` syntax tree is used for * The output of the parser * The output of the renamer * The output of the typechecker The latter, in particular, decorates the tree with information generated by the typechecker; the data types for much of that information is in `TcEvidence`. There are alternatives, of course. Eg have three data types not one; or use more aggressive parameterisation. But the cure seems worse than the disease. By all means suggest improvements, but I'll close this for now as "by design". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 10:00:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 10:00:42 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.0050fb2cee6f36eed46a117482f8db22@haskell.org> #8647: Reduce allocations in `integer-gmp` -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Core | Version: 7.6.3 Libraries | Keywords: integer-gmp Resolution: fixed | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #8638 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.10.1 => 7.8.1 Comment: Yeah, this has been effectively superseded by #9281 (which ironically took two steps forward and one step back... but that's still being worked on) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 10:51:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 10:51:55 -0000 Subject: [GHC] #9804: Layering: Suspicious dependency from Parser to TcEvidence In-Reply-To: <047.cfa5b05c6b1aa1694169baaaf1f8a060@haskell.org> References: <047.cfa5b05c6b1aa1694169baaaf1f8a060@haskell.org> Message-ID: <062.9f4f581806fe67d6f7d36f85cf15fa41@haskell.org> #9804: Layering: Suspicious dependency from Parser to TcEvidence -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): I see. Considering that the typechecker (and possibly the parser and renamer) augment the HsSyn syntax tree, there is another option that is not as invasive as the ones you mentioned above: separate these typechecker decorators into a minimal, lower-level 'TcSyn' module or package. At least HsSyn modules can import these decorators without risks. Maybe these dependencies are already carefully layered this way? Even if they are, the current folder layout gives no indication of this layering and cycles are bound to be introduced over time by unsuspecting contributors. I raised this issue motivated by the experience of trying to run the parser/lexer in isolation (granted, for reasons unrelated to the type checker) and suddenly having to compile hundreds of modules when conceptually parser and lexer should be fairly lower-level components (I am new to the code base so there is also a good chance that part of this is my own ignorance). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 10:58:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 10:58:06 -0000 Subject: [GHC] #9804: Layering: Suspicious dependency from Parser to TcEvidence In-Reply-To: <047.cfa5b05c6b1aa1694169baaaf1f8a060@haskell.org> References: <047.cfa5b05c6b1aa1694169baaaf1f8a060@haskell.org> Message-ID: <062.a920a2d94b1064bd70cd3b9f994d6d00@haskell.org> #9804: Layering: Suspicious dependency from Parser to TcEvidence -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Well `TcEvidence` is the `TcSyn` you seek. If you have a concrete suggestion for how to improve, do by all means suggest it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 15:12:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 15:12:41 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.13e9d2e26bb16f8f126a2afef375f0c5@haskell.org> #8618: can't load .so/.DLL -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This problem still exists in `7.8.3.20141105`. Set `shared: False` in `~/.cabal/config` and try to install `singletons==1.0`. I'm not able to reproduce with GHC HEAD, because of an unrelated issue with th-desugar: https://github.com/goldfirere/th-desugar/issues/17. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 15:13:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 15:13:31 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.57da73ed6e29114e9ba9e3b868fb1443@haskell.org> #8618: can't load .so/.DLL -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler (NCG) => Compiler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 15:20:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 15:20:24 -0000 Subject: [GHC] #8614: Duplicate symbol error when loading text twice In-Reply-To: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> References: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> Message-ID: <057.43c16db95d6d8137fb7fa7103680d343@haskell.org> #8614: Duplicate symbol error when loading text twice -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: I tried `cabal install honi`, but am getting the error: {{{ * Missing C libraries: OpenNI2, freenect }}} Where do I get those, for Ubuntu 14.04. Or better: could you construct a small program that doesn't use `honi` to reproduce this issue? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 16:23:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 16:23:24 -0000 Subject: [GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail In-Reply-To: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> References: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> Message-ID: <060.662aa3c7221d06d33714efe2876f249c@haskell.org> #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail -------------------------------------+------------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Documentation | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Other | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: Runtime crash => Documentation bug * component: Compiler => Documentation Comment: Maybe part of int-e's comment:4 could go into to [https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/runtime- control.html#setting-rts-options user's guide]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 16:27:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 16:27:53 -0000 Subject: [GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail In-Reply-To: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> References: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> Message-ID: <060.f76490046e440e261957c10eb73365d7@haskell.org> #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail -------------------------------------+------------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Documentation | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Other | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by thomie: Old description: > I have encountered a strange occurrence with GHC that was causing several > GHC job failures on an SGE cluster. It turned out that there were other > SGE users who needed an absurdly large stack size limit (set via 'ulimit > -s') in the several gigabytes range. The default stack size limit had to > be raised for the entire cluster. > > Any job that was run on a machine where the virtual memory limit was less > than or equal to 2X the stack size limit, GHC would crash with the > following message: > > ghc: failed to create OS thread: Cannot allocate memory > > I am running on GHC 7.6.3 with a 64-bit RedHat Enterprise OS, version > 5.5. > > To reproduce the error, I was able to create the following test case: > > [ ~]$ ulimit -v > unlimited > [ ~]$ ulimit -s > 10240 > [ ~]$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.6.3 > [ ~]$ ulimit -v 200000 > [ ~]$ ulimit -s 100000 > [ ~]$ ghc --version > ghc: failed to create OS thread: Cannot allocate memory > > Several other programs work find using these settings, but GHC > consistently has problems. Is this a fundamental issue with how GHC > operates or can this be addressed? New description: I have encountered a strange occurrence with GHC that was causing several GHC job failures on an SGE cluster. It turned out that there were other SGE users who needed an absurdly large stack size limit (set via 'ulimit -s') in the several gigabytes range. The default stack size limit had to be raised for the entire cluster. Any job that was run on a machine where the virtual memory limit was less than or equal to 2X the stack size limit, GHC would crash with the following message: ghc: failed to create OS thread: Cannot allocate memory I am running on GHC 7.6.3 with a 64-bit RedHat Enterprise OS, version 5.5. To reproduce the error, I was able to create the following test case: [ ~]$ ulimit -v unlimited [ ~]$ ulimit -s 10240 [ ~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 [ ~]$ ulimit -v 2000000 [ ~]$ ulimit -s 1000000 [ ~]$ ghc --version ghc: failed to create OS thread: Cannot allocate memory [ ~]$ ulimit -s 500000 [ ~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 Several other programs work find using these settings, but GHC consistently has problems. Is this a fundamental issue with how GHC operates or can this be addressed? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 16:47:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 16:47:00 -0000 Subject: [GHC] #8613: simplifier ticks exhausted In-Reply-To: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> References: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> Message-ID: <059.15272c3ae83809d51af8e989d9756e01@haskell.org> #8613: simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: The `repa` library is not compatible with `base-4.8` yet (cabal hell), so I'm not able to reproduce this with HEAD at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 16:48:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 16:48:26 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.965e9823d39c1f51aaa0dae758e1839b@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Comment (by simonpj): Wiki page https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#Usingstandardderivingforgenericfunctions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 16:55:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 16:55:42 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.22a1d295ea5bb6cf439fb316f3028237@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Comment (by dreixel): I need to update that page. On it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 18:18:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 18:18:28 -0000 Subject: [GHC] #8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment In-Reply-To: <051.3280a80c672c79dc5007718f42008b81@haskell.org> References: <051.3280a80c672c79dc5007718f42008b81@haskell.org> Message-ID: <066.f12d3189e0e3464d90293c28fe3eab58@haskell.org> #8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment -------------------------------------+------------------------------------- Reporter: | Owner: ekmett schernichkin | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): `mallocForeignPtrBytes` provides no alignment guarantees. You should in theory need to pad your request by `(alignment - 1)` bytes and align the resulting memory by hand. We're missing a `mallocForeignPtrBytesAligned`, which would behave like `allocaBytesAligned` which probably should become a separate issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 18:53:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 18:53:43 -0000 Subject: [GHC] #9806: malloc and mallocArray ignore Storable alignment requirements Message-ID: <045.326ba18e768a85e91e35911674b0f3ff@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 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 8627 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Not sure if this is a bug or a feature request: `allocaBytesAligned` exists and allocates a new pinned byte array with a given alignment. It is used for both `alloca` and `allocaArray`. However, we don't currently have such a facility with `malloc`. `malloc` and `mallocArray` currently just invoke `mallocBytes`, and `mallocBytes` requests memory without alignment guarantees, so the resulting memory might well violate required `Storable` `alignment` for the result. We don't currently pad things out or get properly aligned memory. It strikes me that we should in theory add `mallocBytesAligned`, and switch `malloc` and `mallocArray` to invoke it instead of `mallocBytes`. `Foreign.Marshal.Alloc.mallocBytes` just invokes system `malloc`, so it seems that `memalign` or `posix_memalign` would be suitable. In theory `_malloc` on the system is probably aligning to a pretty common unit size, but if you start doing SIMD stuff you'll start seeing 16 byte alignment requirements, folks who care about cache architecture for example can have 128 byte alignments to pad things to separate cache lines. We probably haven't noticed since you likely get back bytes with slot- sized alignment just by construction, so if your alignment requirements stay in the <= 8 range you'll be okay, but for larger alignments it appears you'd just get wrong answers. If something more subtle is going on here (e.g. an `alignment` bigger than some threshold wont be respected or that users should explicitly expect `mallocArray` to silently allocate an array with the wrong alignment) that I missed then we definitely need better documentation to address the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 18:54:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 18:54:48 -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.87794ac60eb88d48b0711a483c2fc4a1@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8627 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * related: 8627 => #8627 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 18:55:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 18:55:24 -0000 Subject: [GHC] #8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment In-Reply-To: <051.3280a80c672c79dc5007718f42008b81@haskell.org> References: <051.3280a80c672c79dc5007718f42008b81@haskell.org> Message-ID: <066.5c818a6e902ec269c7b77aaead65c62f@haskell.org> #8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment -------------------------------------+------------------------------------- Reporter: | Owner: ekmett schernichkin | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9806 Type of failure: | Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * related: => #9806 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 18:56:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 18:56:23 -0000 Subject: [GHC] #8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment In-Reply-To: <051.3280a80c672c79dc5007718f42008b81@haskell.org> References: <051.3280a80c672c79dc5007718f42008b81@haskell.org> Message-ID: <066.cd41025dd18898fbfacab92cd681b18c@haskell.org> #8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment -------------------------------------+------------------------------------- Reporter: | Owner: ekmett schernichkin | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9806 Type of failure: | Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Leaving this ticket open to address the documentation issue. I've opened #9806 to address potential library changes though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 19:43:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 19:43:52 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.f2c94a8eebfa5df130f26b62b2c8fb31@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: TH_Depends | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:71 GregWeber]: > I added the documentation: https://phabricator.haskell.org/D481 Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 21:13:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 21:13:01 -0000 Subject: [GHC] #3134: encodeFloat . decodeFloat In-Reply-To: <045.24712bc58e93c54f33f4f129effc8533@haskell.org> References: <045.24712bc58e93c54f33f4f129effc8533@haskell.org> Message-ID: <060.9ff72d3bf0334f9447a77818ac390ef0@haskell.org> #3134: encodeFloat . decodeFloat -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 21:19:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 21:19:37 -0000 Subject: [GHC] #9807: Clarify warning if LLVM is not found by configure Message-ID: <049.ad5e3d70fc50bb323fb6edb8157fac2f@haskell.org> #9807: Clarify warning if LLVM is not found by configure -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When running `./configure` to build GHC, and `opt` is not found, the current output is: > : > Warning: Couldn't figure out LLVM version! > Make sure you have installed LLVM > ghc: could not execute: opt > failed to compile When I first saw this, I thought that this was causing the entire compiler build to fail. To clarify that this isn't a critical error, should it be something more like: > checking for llvm... no -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 22:24:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 22:24:56 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.7f16c4da196d9e4d71fc95e42201efea@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: TH_Depends | Blocking: | Differential Revisions: Phab:D481 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D481 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 17 22:57:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Nov 2014 22:57:32 -0000 Subject: [GHC] #9808: Add data-dir to InstalledPackageInfo Message-ID: <044.d7df9b805388be68f8a820b34b606910@haskell.org> #9808: Add data-dir to InstalledPackageInfo -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, the data directory of a package is not stored in the package database. This is fine for programs produced by GHC, where programs know the location of their own data files through the `Paths_packagename` module, but it's not sufficient for programs that do not have direct access to the local filesystem. Programs produced by GHCJS should be able to load their data files over HTTP. If GHCJS would know the `data-dir` location of all packages, it could make the data files for all dependencies available when linking, and generate a `FilePath -> URI` mapping table. The best it can currently do is making all files on the hard drive available. I have a patch for this that I'll submit once I've figured out how Phabricator works ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 00:07:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 00:07:45 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.ddf56a6422270726e093bf1bedfa8982@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dredozubov): * owner: => dredozubov -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 00:13:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 00:13:10 -0000 Subject: [GHC] #8596: Add support for "reponse files" to workaround Windows command line length limitations (was: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)") In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.0b3bd50c2c8b9f465418ff9a018fc0ae@haskell.org> #8596: Add support for "reponse files" to workaround Windows command line length limitations -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request * architecture: x86 => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:19:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:19:54 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MDU3OiBSZW1vdmUgL3Vzci9iaW4v4oCmIHJl?= =?utf-8?q?ferences?= In-Reply-To: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> References: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> Message-ID: <062.80fdc66387eaa2d2116efa1e299d764e@haskell.org> #9057: Remove /usr/bin/? references -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: closed Priority: low | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D237 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d997ca85a33f34f9f461096eb1b25d5f25b53072/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d997ca85a33f34f9f461096eb1b25d5f25b53072" Don't use absolute paths for perl in validate Summary: This will *not* work on NixOS for example. Reviewers: austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D479 GHC Trac Issues: #9057 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:19:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:19:54 -0000 Subject: [GHC] #7653: incorrect handling of StackOverflow exception in the event manager In-Reply-To: <042.be95d33a48a39c0da3d08d74cdb29185@haskell.org> References: <042.be95d33a48a39c0da3d08d74cdb29185@haskell.org> Message-ID: <057.e8c358a27d00d59a6195ff24099b524c@haskell.org> #7653: incorrect handling of StackOverflow exception in the event manager -----------------------------------+------------------------------------ Reporter: nus | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"a520761d065a84838896e8dd09d8aaec77480d60/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a520761d065a84838896e8dd09d8aaec77480d60" Remove outdated TODO in TimeManager Summary: It describes a work around Trac #3838, but it is already fixed and the workaround removed, Trac #7653 Test Plan: not needed Reviewers: hvr, Mikolaj, austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D478 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:19:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:19:54 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.1e41dd7a9c5766644da7b53205e3a67d@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: TH_Depends | Blocking: | Differential Revisions: Phab:D481 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"0515055abfcf5957d7a957607b4785320627fd65/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0515055abfcf5957d7a957607b4785320627fd65" document addDependentFile uses contents, not mtime Reviewers: austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D481 GHC Trac Issues: #4900 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:19:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:19:54 -0000 Subject: [GHC] #9801: Make listArray fuse In-Reply-To: <045.f98eb8db084a68856be2223df4e40101@haskell.org> References: <045.f98eb8db084a68856be2223df4e40101@haskell.org> Message-ID: <060.b871bfbeacbe2c1e43c6eaa8fa97b357@haskell.org> #9801: Make listArray fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D474 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"bc68ed02e52d8e1c201aff16c4464fd0ca53d0bc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bc68ed02e52d8e1c201aff16c4464fd0ca53d0bc" Make listArray fuse Summary: Make listArray fuse with a list producer. Note: if code size increases too much, we can fix that with some `RULES`. Reviewers: nomeata, hvr, austin, ekmett, simonmar, bgamari Reviewed By: bgamari Subscribers: bgamari, thomie, carter Differential Revision: https://phabricator.haskell.org/D474 GHC Trac Issues: #9801 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:19:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:19:54 -0000 Subject: [GHC] #3838: Performance issues with blackholes In-Reply-To: <047.ef7e7bc3345d4bdf14652daf490fba4d@haskell.org> References: <047.ef7e7bc3345d4bdf14652daf490fba4d@haskell.org> Message-ID: <062.af05ca3dcf69e96ef1301311e769583c@haskell.org> #3838: Performance issues with blackholes --------------------------------------------+------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.14 branch Component: Runtime System | Version: 6.12.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: --------------------------------------------+------------------------------ Comment (by Austin Seipp ): In [changeset:"a520761d065a84838896e8dd09d8aaec77480d60/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a520761d065a84838896e8dd09d8aaec77480d60" Remove outdated TODO in TimeManager Summary: It describes a work around Trac #3838, but it is already fixed and the workaround removed, Trac #7653 Test Plan: not needed Reviewers: hvr, Mikolaj, austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D478 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:21:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:21:50 -0000 Subject: [GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X In-Reply-To: <043.14751a04063e97452853ca5e57a712e1@haskell.org> References: <043.14751a04063e97452853ca5e57a712e1@haskell.org> Message-ID: <058.16426b318d1777bcdadf8298df25a88e@haskell.org> #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X -------------------------------------+------------------------------------- Reporter: kseo | Owner: simonmar Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): [https://hg.python.org/cpython/file/1855b5c3da61/Modules/posixmodule.c#l16074 Python] (warning: big file) uses [https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/sysconf.3.html _SC_NPROCESSORS_ONLN]. "The number of processors currently online". Whatever that means. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:32:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:32:39 -0000 Subject: [GHC] #9801: Make listArray fuse In-Reply-To: <045.f98eb8db084a68856be2223df4e40101@haskell.org> References: <045.f98eb8db084a68856be2223df4e40101@haskell.org> Message-ID: <060.a8526182208c072b5c88720d2b063f7a@haskell.org> #9801: Make listArray fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D474 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:42:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:42:31 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.3c9dc6341114785c36cdf9ee74aed1f8@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): The comment [https://github.com/ghc/ghc/blob/74a6a8a979837d1344fc3236ad6fc4ca76ea49a7/utils /ghc-pkg/Main.hs#L1984 "Big fat hairy race condition"] might have something to do with this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:46:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:46:48 -0000 Subject: [GHC] #9809: Overwhelming the TimerManager Message-ID: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> #9809: Overwhelming the TimerManager -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was talking on IRC with davean about an issue that potentially could have been related to STM (I don't think it is at all after investigating) and I reduced the issue to the following program: {{{#!hs -- Main.hs module Main where import Control.Monad import Control.Concurrent import Control.Concurrent.STM import System.Environment main :: IO () main = do as <- getArgs case as of ["-f"] -> replicateM_ 100000 . void . forkIO . void $ registerDelay 10 _ -> replicateM_ 100000 . void $ registerDelay 10 threadDelay 1000 }}} This ends up registering a lot of events with the TimerManager. With the "-f" flag it does so from many threads and when run that way it appears to eventually overwhelm the TimerManager and causing over 350 MB total memory in use. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20141115 $ ghc -O2 -threaded -debug Main.hs -o Main-head ... $ ./Main-head -f +RTS -s 3,566,966,936 bytes allocated in the heap 4,200,021,784 bytes copied during GC 118,273,720 bytes maximum residency (96 sample(s)) 12,649,480 bytes maximum slop 354 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 6350 colls, 0 par 2.430s 2.434s 0.0004s 0.0073s Gen 1 96 colls, 0 par 7.438s 7.441s 0.0775s 0.2526s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.002s ( 0.002s elapsed) MUT time 0.461s ( 0.460s elapsed) GC time 9.869s ( 9.875s elapsed) EXIT time 0.003s ( 0.003s elapsed) Total time 10.336s ( 10.340s elapsed) Alloc rate 7,741,472,461 bytes per MUT second Productivity 4.5% of total user, 4.5% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} Running without forking many threads and the total memory in use stays low (3 MB). {{{ 154,305,648 bytes allocated in the heap 16,922,272 bytes copied during GC 1,378,608 bytes maximum residency (3 sample(s)) 28,520 bytes maximum slop 3 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 298 colls, 0 par 0.056s 0.056s 0.0002s 0.0015s Gen 1 3 colls, 0 par 0.005s 0.005s 0.0017s 0.0047s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 0.148s ( 0.148s elapsed) GC time 0.061s ( 0.061s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.211s ( 0.210s elapsed) Alloc rate 1,042,557,595 bytes per MUT second Productivity 70.8% of total user, 71.2% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} Using 7.6.3, things don't get out of hand, also with 3 MB total memory use. {{{ $ ./Main-7.6.3 -f +RTS -s 213,519,392 bytes allocated in the heap 116,111,712 bytes copied during GC 505,080 bytes maximum residency (11 sample(s)) 113,032 bytes maximum slop 3 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 403 colls, 0 par 0.33s 0.33s 0.0008s 0.0028s Gen 1 11 colls, 0 par 0.01s 0.01s 0.0011s 0.0019s TASKS: 3 (1 bound, 2 peak workers (2 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 1.99s ( 1.50s elapsed) GC time 0.34s ( 0.34s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2.33s ( 1.84s elapsed) Alloc rate 107,426,859 bytes per MUT second Productivity 85.5% of total user, 108.1% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} I looked for causes and eliminated any `STM` interactions causing problems (`STM` shows up in the `Unique` values and in creating a `TVar` for the registered delay) but did discover that the `emTimeouts` queue gets very large at some point when executing with "-f". If I print the size of `expired` on this line: https://github.com/ghc/ghc/blob/021b7978d14799bae779907faf7490cfd21b3f46/libraries/base/GHC/Event/TimerManager.hs#L226 I end up seeing somewhere from 4 to 20 events for a while then eventually it jumps up to 80000 or so. Perhaps davean can chime in about the particular use case that he has that I reduced to this simple program for a more real world use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:55:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:55:37 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.8c76b87f33253958e0bc5fe2554d9ba7@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by janm): Replying to [comment:1 thomie]: > The comment [https://github.com/ghc/ghc/blob/74a6a8a979837d1344fc3236ad6fc4ca76ea49a7/utils /ghc-pkg/Main.hs#L1984 "Big fat hairy race condition"] might have something to do with this. That comment is in the MINGW32 host or target branch of the #if, dealing with the case where renameFile can't rename over an existing file on the Win32 platform. The real race is depending on renameFile at all, as in the #else case of of that #if, as is the case on the platform I'm using, FreeBSD. The "atomic property" referred to in the comment here is for single- process execution, the race I'm talking about is the race between two processes to call renameFile. A better approach would be for the process to open the targetFile with O_EXCL (and create it with O_CREAT if it doesn't exist), and hold it open while doing the atomic rename on top of the target. That way the targetFile is used a lock to synchronise updates between concurrent processes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 01:59:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 01:59:48 -0000 Subject: [GHC] #8573: "evacuate: strange closure type 0" when creating large array In-Reply-To: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> References: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> Message-ID: <057.307981609a99d8140835e094ccfaf992@haskell.org> #8573: "evacuate: strange closure type 0" when creating large array ----------------------------------------+---------------------------- Reporter: nad | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------- Comment (by thomie): Is this a x86 problem only? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 02:06:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 02:06:06 -0000 Subject: [GHC] #8572: Building an empty module with profiling requires profiling libraries for integer-gmp In-Reply-To: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> References: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> Message-ID: <059.ee5a282fdc3fd9a9445f181f7041028c@haskell.org> #8572: Building an empty module with profiling requires profiling libraries for integer-gmp -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 02:32:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 02:32:35 -0000 Subject: [GHC] #8568: internal error: allocation of ... bytes too large In-Reply-To: <047.44f15a8730cfbfb111ae73ca03abf808@haskell.org> References: <047.44f15a8730cfbfb111ae73ca03abf808@haskell.org> Message-ID: <062.2e2a6f5c37c2f318a5ae3fe9dd94406a@haskell.org> #8568: internal error: allocation of ... bytes too large -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #9647 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime crash Old description: > Running the following GHCi session: > {{{ > import GHC.DataSize > import qualified Data.HashTable.IO as HT > import Control.Monad > t <- HT.new :: IO (HT.BasicHashTable Int Char) > forM_ [0..100000] $ \i -> HT.insert t i 'a' > recursiveSize t > }}} > results in the following error: > {{{ > : internal error: allocation of 1208480 bytes too large (GHC > should have complained at compile-time) > (GHC version 7.6.3 for x86_64_apple_darwin) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Abort trap: 6 > }}} New description: Running the following program after normal compilation: {{{ import GHC.DataSize import qualified Data.HashTable.IO as HT import Control.Monad main = do t <- HT.new :: IO (HT.BasicHashTable Int Char) forM_ [0..100000] $ \i -> HT.insert t i 'a' recursiveSize t return () }}} results in the following error: {{{ internal error: allocation of 1208480 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_linux) }}} To reproduce, first: `cabal install ghc-datasize hashtables`. -- Comment: Can not install dependencies with ghc-7.9.20141115, so don't know if this fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 02:47:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 02:47:18 -0000 Subject: [GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.a3c8005a531dd5ac870237dd8d68b1a2@haskell.org> #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) Comment: With HEAD the error is now: {{{ $ ghc-7.9.20141115 test.hs ... Could not deduce (Data a) arising from a use of ?k? from the context (Typeable (Shape n a)) bound by the instance declaration at test.hs:33:1-34 or from (n ~ 'S r) bound by a pattern with constructor :* :: forall a (r :: Nat). a -> Shape r a -> Shape ('S r) a, in an equation for ?gfoldl? at test.hs:33:1-34 Possible fix: add (Data a) to the context of the data constructor ?:*? or the type signature for gfoldl :: (forall d b. Data d => c (d -> b) -> d -> c b) -> (forall g. g -> c g) -> Shape n a -> c (Shape n a) or the instance declaration ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 02:53:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 02:53:01 -0000 Subject: [GHC] #8559: Compiling dph-lifted fails with "NoSpecConstr" not in scope In-Reply-To: <047.bfd0a661fd10de18ea4220effdf6c9b9@haskell.org> References: <047.bfd0a661fd10de18ea4220effdf6c9b9@haskell.org> Message-ID: <062.0ac7328e84010e9c56386257ba1b622f@haskell.org> #8559: Compiling dph-lifted fails with "NoSpecConstr" not in scope -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Data | Version: 7.7 Parallel Haskell | Keywords: Resolution: worksforme | Architecture: powerpc64 Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: DPH is no longer built by default, see: "[https://www.haskell.org/pipermail/ghc-devs/2014-August/006189.html I'm going to disable DPH until someone starts maintaining it]". Since then, these [https://phabricator.haskell.org/D302 commits] were made to fix the DPH build. Please open a new ticket if anyone runs into problems building dph in the future. {{{ commit 27f7552745fa320e72096b30b08558b7a275bbcc Author: Geoffrey Mainland <> Date: Thu Oct 2 17:39:34 2014 -0400 Make Applicative-Monad fixes for tests. commit 710bc8d77be454243ae8de2a1fb9070b72b525c4 Author: Geoffrey Mainland <> Date: Wed Aug 27 22:33:44 2014 -0400 Update primitive, vector, and dph submodules. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 02:54:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 02:54:41 -0000 Subject: [GHC] #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` In-Reply-To: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> References: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> Message-ID: <061.a1e7b7526d7ae2962dc85cd500a84062@haskell.org> #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.6.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 02:58:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 02:58:12 -0000 Subject: [GHC] #9809: Overwhelming the TimerManager In-Reply-To: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> References: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> Message-ID: <063.ec7ac2a7274d7390b862ae3da7d1fca9@haskell.org> #9809: Overwhelming the TimerManager -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 03:16:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 03:16:48 -0000 Subject: [GHC] #8614: Duplicate symbol error when loading text twice In-Reply-To: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> References: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> Message-ID: <057.a1e0c10508b8a4b680a931793132ba4f@haskell.org> #8614: Duplicate symbol error when loading text twice -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: #7030 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #7030 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 03:35:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 03:35:40 -0000 Subject: [GHC] #9809: Overwhelming the TimerManager In-Reply-To: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> References: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> Message-ID: <063.2ca9448530a7b649cb2fbbb7e03fe999@haskell.org> #9809: Overwhelming the TimerManager -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by davean): * cc: davean (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 03:39:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 03:39:19 -0000 Subject: [GHC] #9809: Overwhelming the TimerManager In-Reply-To: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> References: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> Message-ID: <063.c9964ab5c47d3b404649a7011b0a3c02@haskell.org> #9809: Overwhelming the TimerManager -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by davean): My specific use case involved TCP connections which were waiting on data from a TChan. If the data did not arrive soon enough, it needed to stop waiting on the TChan and do some other work. After which it would either come back and listen again or not. Previously I was managing in the range of 40k per instance for months at a time without issue (excursions to 100k had occurred). Currently (with 7.8.3 and admittedly slightly different server code) I'm not safely able to handle more then around 6k per instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 03:46:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 03:46:06 -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.5b601f8ec8afa7b958f84327150d85e9@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 | Version: (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high * milestone: => 7.10.1 Old description: > Consider > {{{ > {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances #-} > type family F a > type instance F () = F () > data A where > A :: F () ~ () => A > x :: A > x = A > }}} > > On GHC 7.6.3 it yields a context reduction stack overflow (despite F () > ~ () being put into the ?solved funeqs? list). > > In HEAD, a recursive dictionary is built, but then detected: > {{{ > [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 7.7.20131108 for x86_64-unknown-linux): > Cycle in coercion bindings > [[cobox_ayX{v} [lid] > = CO main:Foo.TFCo:R:F(){tc rob}[0] ; cobox_ayZ{v} [lid], > cobox_ayZ{v} [lid] = CO cobox_ayX{v} [lid] ; cobox_az0{v} > [lid]]] > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} > > Either this panic needs to be turned into an error, or we need to prevent > recursive dictionaries for when solving funeqs (similar to how we do it > for `Coercible`). New description: Consider {{{ {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances #-} type family F a type instance F () = F () data A where A :: F () ~ () => A x :: A x = A main = seq A (return ()) }}} On GHC 7.6.3 it yields a context reduction stack overflow (despite F () ~ () being put into the ?solved funeqs? list). In HEAD, a recursive dictionary is built, but then detected: {{{ [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131108 for x86_64-unknown-linux): Cycle in coercion bindings [[cobox_ayX{v} [lid] = CO main:Foo.TFCo:R:F(){tc rob}[0] ; cobox_ayZ{v} [lid], cobox_ayZ{v} [lid] = CO cobox_ayX{v} [lid] ; cobox_az0{v} [lid]]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Either this panic needs to be turned into an error, or we need to prevent recursive dictionaries for when solving funeqs (similar to how we do it for `Coercible`). -- Comment: Trying to compile the example from the description with ghc-7.9.20141115 results in GHC using lots of memory, making my machine unusable until I kill the process. This seems like a regression, setting priority to high. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 03:50:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 03:50:47 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.fa32675dc9623055dd734873a61c4af4@haskell.org> #8545: Reorganize Git repositories -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: fixed | Keywords: git Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8251 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: All that is left is ghc-tarballs, which is handled in #9218 and Phab:D339. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 03:54:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 03:54:11 -0000 Subject: [GHC] #8544: Auto-Reference ticket-related branches in tickets In-Reply-To: <046.985a94d43cb4fdc4ae80a7a56866d975@haskell.org> References: <046.985a94d43cb4fdc4ae80a7a56866d975@haskell.org> Message-ID: <061.631cddd7b4b51e780a938668ccb387ca@haskell.org> #8544: Auto-Reference ticket-related branches in tickets -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: infoneeded request | Milestone: Priority: normal | Version: 7.6.3 Component: Trac & Git | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: nomeata: is this still needed, now that we have Phabricator for review? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 03:57:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 03:57:37 -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.38cd4474dce7367c9af34dfcdfc56cca@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: patch Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ekmett (added) * status: infoneeded => patch Comment: yalas added a new patch, which needs to be reviewed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 04:03:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 04:03:17 -0000 Subject: [GHC] #8538: confusing specialization CORE warning, also can't mark type class instances INLINEABLE unless class defn is marked INLINEABLE In-Reply-To: <045.0346f50016bea4aa3ebc93806a21256a@haskell.org> References: <045.0346f50016bea4aa3ebc93806a21256a@haskell.org> Message-ID: <060.ca3e8f4a493299a9809546975c3f110e@haskell.org> #8538: confusing specialization CORE warning, also can't mark type class instances INLINEABLE unless class defn is marked INLINEABLE -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Ha! This now compiles, using ghc-7.9.20141115. Maybe we should add a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 04:03:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 04:03:52 -0000 Subject: [GHC] #9810: encodeFloat 1 2047 = -1024.0 Message-ID: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> #9810: encodeFloat 1 2047 = -1024.0 -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When the following code is compiled with optimization, it prints `-1024.0`, without optimization the result is `Infinity`. {{{#!hs main = print ((encodeFloat 1 2047) :: Double) }}} I think this might be caused by changes in decoding doubles in `integer- gmp2`. While `decodeFloat` is lossy, since we can not represent exceptional values, `encodeFloat` should never give a different answer here. Also `cgrun044` now gives a different result when compiled with optimization. It was broken anyway, since it claims some values are `NaN`, while actually `Infinity` is printed (also with 7.8), but it used to give the same answer regardless of optimization with GHC 7.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 04:12:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 04:12:12 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.967e7991dcb213dac9b1a7cce409f4a1@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * version: 7.6.2 => 7.8.3 Comment: Yes, I get the exact same behavior in 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 04:17:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 04:17:51 -0000 Subject: [GHC] #8573: "evacuate: strange closure type 0" when creating large array In-Reply-To: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> References: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> Message-ID: <057.918fd1be0ec986ecff0d715bf8adad96@haskell.org> #8573: "evacuate: strange closure type 0" when creating large array -------------------------------------+------------------------------------- Reporter: nad | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: simonmar (added) * component: Compiler => Runtime System * architecture: x86 => Unknown/Multiple Comment: No, it is not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 04:25:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 04:25:03 -0000 Subject: [GHC] #7678: GHC should compile cleanly with clang In-Reply-To: <052.9fdbb8596cd8d902084a24d3fe32e9db@haskell.org> References: <052.9fdbb8596cd8d902084a24d3fe32e9db@haskell.org> Message-ID: <067.bd44fc766675b26e12f5db0da678c392@haskell.org> #7678: GHC should compile cleanly with clang -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice thoughtpolice | Status: closed Type: bug | Milestone: 7.8.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: clang Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: 7602 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:15 hvr]: > fyi, I'm afraid the situation has changed; see [http://www.haskell.org/pipermail/ghc-devs/2014-April/004489.html this email] for details. The followup [https://www.haskell.org/pipermail/ghc- devs/2014-April/004631.html email] let's me believe this issue is really fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 04:25:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 04:25:58 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.31132bfb4fbc58fd2509a76fccb36050@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: #8480 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: The patches to Alex and Happy have been released. I think the immediate issue here is fixed. See #7678 for the general issue to accommodate the clang preprocessor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 04:29:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 04:29:24 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.6ed70513c42566742fd3075ed7aaae13@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by ezyang): We backed out these patches, see #9706 for the new plan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 04:29:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 04:29:32 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.3f395ecb0480f4986ddc54d249159aff@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by ezyang): We backed out these patches, see #9706 for the new plan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 04:51:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 04:51:18 -0000 Subject: [GHC] #8527: The ordering of -I directives should be consistent with the ordering of -package directives (was: container's Typeable.h is being shadowed by base's Typeable.h during preprocessing) In-Reply-To: <044.9e25da1df7745d2b97e644bd03393477@haskell.org> References: <044.9e25da1df7745d2b97e644bd03393477@haskell.org> Message-ID: <059.24eecc42fd2dbbc9045c01641922f266@haskell.org> #8527: The ordering of -I directives should be consistent with the ordering of -package directives -------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.7 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Old description: > Here's a reduced test case: > > == cpp.hs == > {{{ > #!haskell > {-# LANGUAGE CPP #-} > > #include "Typeable.h" > > main = return () > }}} > > == command line == > {{{ > $ ghc-stage2 -c -package base cpp.hs > > In file included from cpp.hs:4:0: > > /home/patrick/code/ghc/libraries/base/include/Typeable.h:17:2: > warning: #warning is obsolete and will be removed in > GHC 7.10 [-Wcpp] > #warning is obsolete and will be removed in GHC 7.10 > ^ > compilation IS NOT required > $ ghc-stage2 -c -package base -package containers cpp.hs > compilation IS NOT required > $ ghc-stage2 -c -package containers -package base cpp.hs > }}} > > Notice that if I pass `-package containers` to ghc, the cpp warning from > Typeable.h (from the base library) doesn't appear. This is because > containers also has a Typeable.h in its include path, and in the > invocation of the preprocessor, containers' include path precedes base's > no matter how I order the `-package` directives. > > This behavior is intuitive and limiting. To fix this, I think that the > ordering of -I directives passed to the preprocessor should be consistent > with the ordering of -package directives passed to ghc. For example, in > the above test case, a warning should be shown in the 1st and 2nd > invocations of ghc but not the 3rd, because in the 3rd invocation > containers precedes base. > > Does this sound okay? New description: Here's a reduced test case: == cpp.hs == {{{ #!haskell {-# LANGUAGE CPP #-} #include "Typeable.h" main = return () }}} == command line == {{{ $ ghc-stage2 -c -package base cpp.hs In file included from cpp.hs:4:0: /home/patrick/code/ghc/libraries/base/include/Typeable.h:17:2: warning: #warning is obsolete and will be removed in GHC 7.10 [-Wcpp] #warning is obsolete and will be removed in GHC 7.10 ^ compilation IS NOT required $ ghc-stage2 -c -package base -package containers cpp.hs compilation IS NOT required $ ghc-stage2 -c -package containers -package base cpp.hs }}} Notice that if I pass `-package containers` to ghc, the cpp warning from Typeable.h (from the base library) doesn't appear. This is because containers also has a Typeable.h in its include path, and in the invocation of the preprocessor, containers' include path precedes base's no matter how I order the `-package` directives. This behavior is unintuitive and limiting. To fix this, I think that the ordering of -I directives passed to the preprocessor should be consistent with the ordering of -package directives passed to ghc. For example, in the above test case, a warning should be shown in the 1st and 2nd invocations of ghc but not the 3rd, because in the 3rd invocation containers precedes base. Does this sound okay? -- Comment (by thomie): Work has started: {{{ commit 574ccfa231ca05d03d1da9d31e5bc81e74cc5e1e Author: Patrick Palka Date: Tue Nov 26 11:46:59 2013 -0500 Respect the ordering of -package directives }}} But that commit was later reverted in fac831fd1377bcce5ef7513ab35a83661877f14c. With `ghc-7.9.20141115`, the warning from the description is always shown, regardless of the ordering of the package directives. So something ''has'' changed. Note: "Typeable.h" might be removed when you read this. That doesn't mean that this issue is fixed though. A test should be added as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 05:48:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 05:48:14 -0000 Subject: [GHC] #9811: constant folding with infinities is wrong Message-ID: <047.e788a95f0fc3d0195124bcc714677e40@haskell.org> #9811: constant folding with infinities is wrong -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #9810 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ main = let big = 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 :: Double in print (big * big - big * big) }}} prints NaN when compiled without optimizations but 0.0 when compiled with optimizations. Or, `print (big * big / 2)` prints Infinity when compiled without optimizations but 8.98846567431158e307 when compiled with optimizations (this number is `fromRational (toRational (1/0) / 2)`). The cause is the conversions that go on between Rational and Double in PrelRules (in the functions doubleOp2, mkDoubleVal, convFloating). Ideally, we would have an accurate model of floating-point arithmetic on the target machine, but for now it would be an improvement to just not constant fold when the result is not a finite floating-point number. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 05:54:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 05:54:18 -0000 Subject: [GHC] #9810: encodeFloat 1 2047 = -1024.0 In-Reply-To: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> References: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> Message-ID: <059.8c86fe0b86f9a76adbb823583bce1e57@haskell.org> #9810: encodeFloat 1 2047 = -1024.0 -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9811 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #9811 Comment: The old correct behavior depended somewhat precariously on being able to round-trip floating-point infinities through `toRational/fromRational`. This causes other wrong behavior, see #9811. While the situation with constant folding of floating-point is not ideal anyways, we should restore the old behavior of `toRational` (`decodeFloat`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 06:56:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 06:56:24 -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.90736e79216cd7e856dc55ce96faa3fa@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: patch Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Scott, that is an amazingly thorough summary. Yalas, the patch looks sane to me. It also just helped me catch some issues in my own automatic differentiation code, so that is a sign it is a good thing to have right in `base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 06:56:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 06:56:24 -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.90736e79216cd7e856dc55ce96faa3fa@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: patch Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Scott, that is an amazingly thorough summary. Yalas, the patch looks sane to me. It also just helped me catch some issues in my own automatic differentiation code, so that is a sign it is a good thing to have right in `base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 07:04:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 07:04:51 -0000 Subject: [GHC] #9810: encodeFloat 1 2047 = -1024.0 In-Reply-To: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> References: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> Message-ID: <059.24ab9aaed6c6dfd12ebc3a284cf87e9b@haskell.org> #9810: encodeFloat 1 2047 = -1024.0 -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: ieee Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9811 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: ekmett (added) * keywords: => ieee * owner: => hvr * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 07:39:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 07:39:20 -0000 Subject: [GHC] #9810: encodeFloat 1 2047 = -1024.0 In-Reply-To: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> References: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> Message-ID: <059.5363a45467ee29bd7d52ce01606b4262@haskell.org> #9810: encodeFloat 1 2047 = -1024.0 -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: ieee Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9811 Test Case: | Blocking: | Differential Revisions: Phab:D486 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D486 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 07:04:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 07:04:51 -0000 Subject: [GHC] #9810: encodeFloat 1 2047 = -1024.0 In-Reply-To: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> References: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> Message-ID: <059.24ab9aaed6c6dfd12ebc3a284cf87e9b@haskell.org> #9810: encodeFloat 1 2047 = -1024.0 -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: ieee Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9811 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: ekmett (added) * keywords: => ieee * owner: => hvr * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 09:36:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 09:36:46 -0000 Subject: [GHC] #8544: Auto-Reference ticket-related branches in tickets In-Reply-To: <046.985a94d43cb4fdc4ae80a7a56866d975@haskell.org> References: <046.985a94d43cb4fdc4ae80a7a56866d975@haskell.org> Message-ID: <061.1ca5b6e316b33534199f397d2d019be2@haskell.org> #8544: Auto-Reference ticket-related branches in tickets -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Trac & Git | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: infoneeded => closed * resolution: => wontfix Comment: Nah, probably not worth the effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 09:59:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 09:59:24 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.a052ac17d876e376d7eb9335053b8236@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: simonpj (added) * owner: => ezyang Comment: Plan changed again! Now the idea is to maintain the set of orphan modules reachable from DIRECTLY imported modules, instead of the set of interface files. This ALMOST works. The big problem is when we mkLocalInstance, we need to know (immediately) if it's an orphan or not, because that entry in the instance environment may become enshrined forever if we have a GHCi session involved. I think we can pull this off by moving the logic from MkIface for calculating if an instance is an orphan to the typechecker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 09:56:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 09:56:18 -0000 Subject: [GHC] #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` In-Reply-To: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> References: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> Message-ID: <061.44bf90cbfc54644006f81e34ec611469@haskell.org> #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.6.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): After you bumped this ticket, I looked at it and thought ?hey, that?s useful?. So I pushed this as branch `wip/T8558` now (I want travis to validate it). And only then noticed that I originally reported this :-] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 10:30:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 10:30:15 -0000 Subject: [GHC] #9700: Support C structures in Haskell FFI In-Reply-To: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> References: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> Message-ID: <059.ae4168653f7326d19b3a0c4013c02f44@haskell.org> #9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D252 | -------------------------------------+------------------------------------- Comment (by Yuras): carter: thank you. Unfortunately I already flushed the context out of my mind a number of days ago. But I promise to return to this feature request eventually. svenpanne: Yes, I believe you are correct. Probably it should not mention Int, Char, Float, etc at all. Feel free to fix it. Thanks for taking a look! And just for the record: I still think the low level part, covered by D252, is useful on itself. Please consider merging it into 7.10. At least I appreciate any feedback. I raised that question in a email in ghc-dev few weeks ago, but got no response. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 10:48:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 10:48:11 -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.266809e4faac7685db803a92b729d371@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: patch Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 7.10.1 Comment: I'm not reading the details here, but it sounds as if this is ready for 7.10.1, right? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 11:30:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 11:30:00 -0000 Subject: [GHC] #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` In-Reply-To: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> References: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> Message-ID: <061.4d475d4b7becfb9759e3f87ca714f2c8@haskell.org> #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.6.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"aa1c1b2a364e443ceb11b898cf3e648c14954fd9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="aa1c1b2a364e443ceb11b898cf3e648c14954fd9" Build xhtml and haddock only when `HADDOCK_DOCS=YES` This fixes #8558 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 11:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 11:56:56 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.5f224831d0fed44995c61e1175f8aef3@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: D488 | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => D488 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 13:26:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 13:26:59 -0000 Subject: [GHC] #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` In-Reply-To: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> References: <046.58d7da5028bf9a8ae08210a8bd83e6b5@haskell.org> Message-ID: <061.83e7563c51576ba2c8b8f2d133bf3f70@haskell.org> #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: +1 for reducing the build time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 15:55:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 15:55:12 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.5eaa95c7d798ac93d29a662d6990702f@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid I've got lost here. Would it be possible to start from zero: that is, attach to this ticket the smallest reproducible test case you have, along with instructions for how to reproduce it? Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 16:18:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 16:18:40 -0000 Subject: [GHC] #8560: Derive some generic representation for GADTs (was: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122) In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.1178d52fe76cd3bacbdf0573613c89a1@haskell.org> #8560: Derive some generic representation for GADTs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Rocket Science Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * difficulty: Unknown => Rocket Science * milestone: => ? Old description: > This may be an artifact of issue #8128 (see > https://ghc.haskell.org/trac/ghc/ticket/8128#comment:5), but I'm seeing > examples involving data kinds where Typeable isn't deducible. This could > be an artifact of other problems, BUT since with 7.7 onwards, we have > baked in polykinded Typeable, things should always "just work?" right? > > the error with current head is as follows (and i'm attaching the code + > current finger print too) New description: This may be an artifact of issue #8128 (see https://ghc.haskell.org/trac/ghc/ticket/8128#comment:5), but I'm seeing examples involving data kinds where Typeable isn't deducible. This could be an artifact of other problems, BUT since with 7.7 onwards, we have baked in polykinded Typeable, things should always "just work?" right? the error with current head is as follows (and i'm attaching the code + current finger print too) EDIT: The request here is really for some generic representation derivable for GADTs. This is a Research Problem, but one that would really help a fair amount of ordinary folk. It won't ever work with `Data`, as we now know `Data`, because the types aren't up to the task. But, perhaps some future generic representation will work. The original description remains unchanged above so that readers can make sense of the comments. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 16:20:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 16:20:06 -0000 Subject: [GHC] #8560: Derive some generic representation for GADTs In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.82800626fcf5800b78f43f4e9124a26f@haskell.org> #8560: Derive some generic representation for GADTs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.7 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Rocket Science Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 16:23:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 16:23:19 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.34fd29c68745520dd0527874da9635b7@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by pgj): * owner: => pgj Comment: Wow, I did not even know that such ticket exists. Sorry for missing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 16:27:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 16:27:37 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.138f6f49810b8f73fcf39c818c038c6e@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:2 janm]: > A better approach would be for the process to open the targetFile with O_EXCL (and create it with O_CREAT if it doesn't exist), and hold it open while doing the atomic rename on top of the target. That way the targetFile is used a lock to synchronise updates between concurrent processes. Does the same problem persist with GHC 7.8.x? Unfortunately, I do not own such a beefy hardware, although I may be able to get some help in that respect from the FreeBSD Project. What is the version of the operating system (that is, ideally {{{OSVERSION}}})? I guess the architecture is {{{amd64}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 17:18:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 17:18:52 -0000 Subject: [GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics In-Reply-To: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> References: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> Message-ID: <061.e25b9c0e19da0c1129ae4306e4f38a5a@haskell.org> #9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9043 Test Case: | Blocking: 9043 | Differential Revisions: Phab:D493 | -------------------------------------+------------------------------------- Changes (by dreixel): * status: new => patch * differential: => Phab:D493 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 17:53:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 17:53:11 -0000 Subject: [GHC] #8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread In-Reply-To: <048.d427ad4c249513a7b1f62c90daadde10@haskell.org> References: <048.d427ad4c249513a7b1f62c90daadde10@haskell.org> Message-ID: <063.662bb323e899d5e22c7f4ae55a6112ce@haskell.org> #8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: ekmett Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: invalid | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => invalid Comment: The change you are requesting has to go through the [https://www.haskell.org/haskellwiki/Library_submissions library submission process] first (basically send an email to libraries at haskell.org). Please re-open this ticket when your proposal gets accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:03:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:03:53 -0000 Subject: [GHC] #6138: GHCI Startup Crash with HP 2012.2.0.0 on 64bit OS X 10.6 In-Reply-To: <050.512da14a2ce36c2480bfd514b3fa3a38@haskell.org> References: <050.512da14a2ce36c2480bfd514b3fa3a38@haskell.org> Message-ID: <065.7b349392ea33774668e5f3070f7f1c13@haskell.org> #6138: GHCI Startup Crash with HP 2012.2.0.0 on 64bit OS X 10.6 -------------------------------------+------------------------------------- Reporter: | Owner: MtnViewMark | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: fixed | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: GHCi crash | Related Tickets: #8511 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * version: 7.6.1 => 7.6.3 * resolution: => fixed * related: => #8511 Comment: Since there aren't any reports of ghci segmentation faults with 7.8.3 or HEAD on Mac, and we there won't be another 7.6 release, I'm closing this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:05:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:05:40 -0000 Subject: [GHC] #8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6 In-Reply-To: <048.eda79a65fd24248c19cdd55ed1f00373@haskell.org> References: <048.eda79a65fd24248c19cdd55ed1f00373@haskell.org> Message-ID: <063.8461d4da314cf68bbd92f4c29d8d8e60@haskell.org> #8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6 -------------------------------------+---------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #6138 Differential Revisions: | -------------------------------------+---------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #6138 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:20:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:20:28 -0000 Subject: [GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. In-Reply-To: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> References: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> Message-ID: <062.8dc562e61230738f9a35c64a5efaf2fa@haskell.org> #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3968 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by thomie: Old description: > GHC shows unhelpful error message when using rec keyword and/or mdo > keyword without RecursiveDo extention. > > {{{ > module NoRecursiveDo where > > foo = do > rec str <- return "foo" > putStrLn str > }}} > > {{{ > $ ghc -c NoRecursiveDo.hs > > NoRecursiveDo1.hs:4:5: Parse error in pattern: rec > > }}} > > {{{ > module NoRecursiveDo2 where > > bar = mdo > str <- return "bar" > putStrLn str > }}} > > {{{ > $ ghc -c NoRecursiveDo2.hs > > NoRecursiveDo2.hs:4:9: parse error on input `<-' > > }}} > > {{{ > module NoRecursiveDo3 where > > baz = mdo > putStrLn "baz" > }}} > > {{{ > $ ghc -c NoRecursiveDo3.hs > > NoRecursiveDo3.hs:3:7: > Not in scope: `mdo' > Perhaps you meant `mod' (imported from Prelude) > > }}} > > I think that GHC should suggest to use RecursiveDo extention when using > mdo/rec keyword. New description: GHC shows unhelpful error message when using rec keyword and/or mdo keyword without RecursiveDo extention. {{{ module NoRecursiveDo where foo = do rec str <- return "foo" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo.hs NoRecursiveDo1.hs:4:5: Parse error in pattern: rec Possibly caused by a missing 'do'? }}} {{{ module NoRecursiveDo2 where bar = mdo str <- return "bar" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo2.hs NoRecursiveDo2.hs:4:9: parse error on input `<-' }}} {{{ module NoRecursiveDo3 where baz = mdo putStrLn "baz" }}} {{{ $ ghc -c NoRecursiveDo3.hs NoRecursiveDo3.hs:3:7: Not in scope: `mdo' Perhaps you meant `mod' (imported from Prelude) }}} I think that GHC should suggest to use RecursiveDo extention when using mdo/rec keyword. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:21:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:21:42 -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.76a02378daa4deb13f5dd0f4b2de19c9@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: patch Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"1f6b1ab4b6d7203481bfaf374b014972f7756fb2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1f6b1ab4b6d7203481bfaf374b014972f7756fb2" base: Fix (**) instance for Data.Complex (#8539) Reviewed-by: Edward Kmett Authored-by: Yalas, Scott Turner Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:21:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:21:42 -0000 Subject: [GHC] #9713: Update comment about C helper for dynamic exports. In-Reply-To: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> References: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> Message-ID: <059.3966007f098e2ecfb30679cfbd6c7acf@haskell.org> #9713: Update comment about C helper for dynamic exports. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Other | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"ddb484c2335c75f8fd767f54377e418db400aede/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ddb484c2335c75f8fd767f54377e418db400aede" Update comment about C helper for foreign exports (#9713) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:21:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:21:42 -0000 Subject: [GHC] #9644: mapMaybes documentation contains some gibberish In-Reply-To: <044.8b0e339ed9c82d4dd97bbc57d2bf1135@haskell.org> References: <044.8b0e339ed9c82d4dd97bbc57d2bf1135@haskell.org> Message-ID: <059.fb0da6e4d5809a0ae27f2192e740250c@haskell.org> #9644: mapMaybes documentation contains some gibberish -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"21f9bc434c12e928005d59c494e4f48c242b0613/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="21f9bc434c12e928005d59c494e4f48c242b0613" mapMaybe: Typo in the comment (#9644) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:21:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:21:42 -0000 Subject: [GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 In-Reply-To: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> References: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> Message-ID: <058.11b1b373e8d7f22ec5634688453135fb@haskell.org> #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: aclocal.m4 find Resolution: | perm Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"87cd37b7e61ef90842101a0d2fb1f6c9c8580976/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="87cd37b7e61ef90842101a0d2fb1f6c9c8580976" Fix usage of `find -perm` in aclocal.m4 (#9697) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:22:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:22:36 -0000 Subject: [GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 In-Reply-To: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> References: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> Message-ID: <058.6e3492a45417edc0e9cf530ac1688466@haskell.org> #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.3 System | Keywords: aclocal.m4 find Resolution: fixed | perm Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:27:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:27:02 -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.80ed31495894ef2ba39eb698c6b04295@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: patch Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thoughtpolice): This is almost closed, but I forgot to add a note to the release notes. Incoming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:23:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:23:21 -0000 Subject: [GHC] #9644: mapMaybes documentation contains some gibberish In-Reply-To: <044.8b0e339ed9c82d4dd97bbc57d2bf1135@haskell.org> References: <044.8b0e339ed9c82d4dd97bbc57d2bf1135@haskell.org> Message-ID: <059.883f5e4ad17fd11c8590e5cc23bdb8cd@haskell.org> #9644: mapMaybes documentation contains some gibberish -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: core-libraries-committee@? (added) * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:26:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:26:04 -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.808f2193c24138b40842f23aec3bcbd2@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: patch Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): One minor concern: will the optimizer do the right thing checking `exp_re < 0` and `exp_re > 0`, or will we be better off with `case compare 0 exp_re ...`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:23:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:23:32 -0000 Subject: [GHC] #9713: Update comment about C helper for dynamic exports. In-Reply-To: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> References: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> Message-ID: <059.0e0772dbffe4ef2cc66d1a0cb534c1d7@haskell.org> #9713: Update comment about C helper for dynamic exports. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Other | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:37:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:37:21 -0000 Subject: [GHC] #9368: Add strictly accumulating scanl' to Data.List In-Reply-To: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> References: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> Message-ID: <060.16f30eefb59fd2c294c0a0aba5bf237a@haskell.org> #9368: Add strictly accumulating scanl' to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9345 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => new Comment: {{{ commit d45693a5384460d22a6437b9cda463b4ec4b6a37 Author: David Feuer <> Date: Tue Oct 7 20:51:25 2014 +0200 Make scanl fuse; add scanl' Summary: Make scanl a good producer and a good consumer for fold/build fusion. Add strictly-accumulating scanl', which is required for Data.List.inits. Reviewers: nomeata, austin Reviewed By: austin Subscribers: spacekitteh, thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D314 GHC Trac Issues: #9356 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:30:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:30:13 -0000 Subject: [GHC] #9578: Quoting issue in configure.ac In-Reply-To: <045.51abf4c3113237a495d0f9c59c18c634@haskell.org> References: <045.51abf4c3113237a495d0f9c59c18c634@haskell.org> Message-ID: <060.bf0a728b31c42f7e91a6a19895d13c09@haskell.org> #9578: Quoting issue in configure.ac -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: This was already fixed by 1ec91133, Phab:D304. Sorry I let this slip, Gintas! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:43:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:43:00 -0000 Subject: [GHC] #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknown archs In-Reply-To: <050.ec9d0ec38ab57c70c2fd6acc66f09adc@haskell.org> References: <050.ec9d0ec38ab57c70c2fd6acc66f09adc@haskell.org> Message-ID: <065.1aaeba59839f07757c7b48c22f94b82b@haskell.org> #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknown archs -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen juhpetersen | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Hey Jens, sorry for taking so long. Sergei actually fixed this in c65221bdbdebb0a6e615970cb0ca78abcb4202f8, so this is now fixed. Thank you though (and sorry again!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:43:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:43:19 -0000 Subject: [GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) In-Reply-To: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> References: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> Message-ID: <059.265f72804512cdec38862d8ba3586bbe@haskell.org> #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Runtime | hour) crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"c557f991a9fa6f6afad4850e4f5db6a08fa1cb6c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c557f991a9fa6f6afad4850e4f5db6a08fa1cb6c" Disable AVX for LLVM 3.2 by default (#9391) Due to a bug LLVM generates a C-like frame pointer prelude for functions that use AVX instructions. This causes programs using the GHC calling convention to crash, therefore we simply disable them. People that want to use AVX should consider upgrading to a more current LLVM version. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:43:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:43:20 -0000 Subject: [GHC] #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters In-Reply-To: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> References: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> Message-ID: <059.fabc412754715d4ae5b2a19c9e08c0ed@haskell.org> #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters -------------------------------------+------------------------------------- Reporter: slomo | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8976 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e7b414a3cc0e27049f2608f5e0a00c47146cc46d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e7b414a3cc0e27049f2608f5e0a00c47146cc46d" Fix detection of GNU gold linker if invoked via gcc with parameters Previously the linker was called without any commandline parameters to detect whether bfd or gold is used. However the -fuse-ld parameter can be used to switch between gold and bfd and should be taken into account here. Trac #9336 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:43:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:43:48 -0000 Subject: [GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) In-Reply-To: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> References: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> Message-ID: <059.8a54eed7318e28ad5ab82d09d4cf5262@haskell.org> #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Runtime | hour) crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: OK, merged. Thanks Peter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 18:44:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 18:44:07 -0000 Subject: [GHC] #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters In-Reply-To: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> References: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> Message-ID: <059.b78cdc4f7488e5b493a897e4ba2930ad@haskell.org> #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters -------------------------------------+------------------------------------- Reporter: slomo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Driver | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8976 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:04:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:04:07 -0000 Subject: [GHC] #8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table` In-Reply-To: <044.5f5ec774064a8f6ab1662b91fc1d1daa@haskell.org> References: <044.5f5ec774064a8f6ab1662b91fc1d1daa@haskell.org> Message-ID: <059.af3a4f227d7e949547e23b1ceeb675c3@haskell.org> #8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table` -------------------------------------+------------------------------------- Reporter: jloos | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Please re-open if this issue still exists in 7.8.3. Unfortunately, there won't be another 7.6 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:10:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:10:27 -0000 Subject: [GHC] #8489: clean up dependency and usages handling in interface files In-Reply-To: <044.51af461702f35c8970f506002f551481@haskell.org> References: <044.51af461702f35c8970f506002f551481@haskell.org> Message-ID: <059.acd2439e71c2a427737c6188e18bfa1e@haskell.org> #8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): I don't know what the status is here. Is it cleanup up? I did find this commit: 50d4cd7afd8fdc3efdc3a50b9e8e606336c1cdee {{{ Author: Simon Peyton Jones <> Date: Tue Nov 5 15:17:22 2013 +0000 More comments on Usage and Dependencies }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:11:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:11:46 -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.e5431e8b9f4cb6e68d2868cc4784e86d@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: patch Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a736b517bddaf5271ab7a0989787b120324b19f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a736b517bddaf5271ab7a0989787b120324b19f6" Revert "base: Fix (**) instance for Data.Complex (#8539)" This broke validate due to name shadowing warnings. This reverts commit 1f6b1ab4b6d7203481bfaf374b014972f7756fb2. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:23:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:23:56 -0000 Subject: [GHC] #8484: Compile-time panic In-Reply-To: <045.cfbefb278865add04d816ec807a8ca09@haskell.org> References: <045.cfbefb278865add04d816ec807a8ca09@haskell.org> Message-ID: <060.e1fe2a3f591f60bb015e36a53741f951@haskell.org> #8484: Compile-time panic -------------------------------------+------------------------------------- Reporter: Taymon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Taymon: please re-open if you run into this problem again, ideally with a small testfile and steps to reproduce it. See [wiki:ReportABug]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:26:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:26:33 -0000 Subject: [GHC] #8477: Allow inferring ambiguous types In-Reply-To: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> References: <045.eba11f97886c50dcee3d55a438abd62f@haskell.org> Message-ID: <060.304e773582a7909edbe956ccfd077a76@haskell.org> #8477: Allow inferring ambiguous types -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 8390 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:28:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:28:11 -0000 Subject: [GHC] #8489: clean up dependency and usages handling in interface files In-Reply-To: <044.51af461702f35c8970f506002f551481@haskell.org> References: <044.51af461702f35c8970f506002f551481@haskell.org> Message-ID: <059.28aa2f19977dccd8872629707f63c2e0@haskell.org> #8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by errge): Simon, unfortunately this is not done yet and that is totally on me :( The main task here is to "fix TH module reification to reify direct import list, not usages" So just having more comments is not enought, actual coding (and probably some refactoring) has to happen. On the other hand, I am pretty sure that the better comments will help me to get back up to speed more quickly when I sit down to handle this. I still plan to work on this, so feel free to leave me as owner unless someone else wants to tackle this before me in which case I am happy to discuss more if questions come up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:31:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:31:25 -0000 Subject: [GHC] #8473: Generate table of cost-centre numbers with source locations In-Reply-To: <053.95380650abc814621da8b15bb4430f35@haskell.org> References: <053.95380650abc814621da8b15bb4430f35@haskell.org> Message-ID: <068.198e349a3f0c6f145040117815037382@haskell.org> #8473: Generate table of cost-centre numbers with source locations -------------------------------------+------------------------------------- Reporter: | Owner: lars_e_krueger | Status: new Type: feature | Milestone: request | Version: 7.6.3 Priority: normal | Keywords: Component: Profiling | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #7105 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: 7105 => #7105 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:38:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:38:15 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.a861351155c02e85ce332a38d66f8b91@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D469 | -------------------------------------+------------------------------------- Comment (by goldfire): On Phab:D469, Simon says, about line 328 of !TcExpr: > This smells wrong. tcInferRho ends up calling tcInfer, which makes an OpenKind ReturnTv. But then we unify it with a liftedTypeKind ReturnTv later. > > Complicated and silly. Better if tcInferRho takes the kind it is expecting. Then we have only one ReturnTv, not two; and the whole ReturnTv story is located in tcInfer, rather than having a non-return-ish hack in the typing rule for $ > > Make sense? I've decided: no, this doesn't make sense. The call to `tcInferRho` is to infer the type of the left-hand argument to `$`. This type is a function type `arg -> res`. If it turns out to be unlifted, the `matchExpectedFunTys` will fail. The silliness with the new `ReturnTy` bit isn't about the result of `tcInferRho` -- it's about the result of `matchExpectedFunTys`. So the straightforward refactoring Simon proposes doesn't work. Instead, what we should do here is to unify `arg2_ty`'s kind with `*`. But !TcUnify doesn't have a function for that -- something like `matchExpectedStar`. The closest thing -- `unifyKindX` tells us about sub- kinding relationships, instead of actually unifying the kinds. So, I propose: do nothing for now. It's working, although a little uglily, as is. When we have proper kind equalities and no sub-kinding anymore, this will be easy to fix. Please close the ticket if you agree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:47:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:47:29 -0000 Subject: [GHC] #8465: ./configure fails on ghc-7.6.3: does not find installed libgmp.so.3 and current directory In-Reply-To: <047.989218e88c2fa8a3f6972602c7df02c2@haskell.org> References: <047.989218e88c2fa8a3f6972602c7df02c2@haskell.org> Message-ID: <062.7477c5a94352dabe51de4d57e0c3c0df@haskell.org> #8465: ./configure fails on ghc-7.6.3: does not find installed libgmp.so.3 and current directory -------------------------------------+------------------------------------- Reporter: ygramoel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.6.3 System | Keywords: Resolution: worksforme | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: ygramoel: sorry to hear you ran into this. A lot has changed since you opened this ticket, so I'm closing this for now. Please see [wiki:Building/Preparation] for setting up your system to build GHC. Don't hesitate to open another ticket if you run into problems again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:52:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:52:24 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.46c4e704770df1055722342490cfdfb9@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: 9766 Unknown/Multiple | Related Tickets: #8778 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bgamari): What can we do to make sure this makes it in for 7.10? Perhaps it would make sense to split out the `Data` and `Typeable` changes so the other instances can be merged independently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:54:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:54:20 -0000 Subject: [GHC] #8457: -ffull-laziness does more harm than good In-Reply-To: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> References: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> Message-ID: <059.de358ddb1125c11a992caf1bbefee46a@haskell.org> #8457: -ffull-laziness does more harm than good -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 22:58:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 22:58:54 -0000 Subject: [GHC] #8401: parsec issues In-Reply-To: <047.cbaa79be6f9836aeaa184dc57763560c@haskell.org> References: <047.cbaa79be6f9836aeaa184dc57763560c@haskell.org> Message-ID: <062.906718e5f0c5513a4bc1711d80138580@haskell.org> #8401: parsec issues -------------------------------------+------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Sorry to hear you ran into this issue. Please try the http://haskell.org/platform next time. It comes with parsec pre-installed, and should solve most of these annoying installation problems for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 22:00:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 22:00:01 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.5103aa3e32eda64d4bf9b82023c593bd@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): I have updated ?Phab:D426, ?Phab:D438 and ?Phab:D412 to include documentation about what annotations can be expected against each AST element, and also rebases against current master. The process of documentation showed up a number of shortcomings where annotations were missing or duplicated. I have also changed the `getAnnotation` result from `Maybe SrcSpan` to `[SrcSpan]` and allow multiple annotations of the same type on a given AST element. This means that the horrible `AnnColon2` and similar are now gone. The users of the annotations should be able to work out what is what from the surrounding context. They are once more ready for final review and hopefully merge for 7.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 23:10:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 23:10:10 -0000 Subject: [GHC] #8398: reify module list in TH In-Reply-To: <044.b09c2294dcb548cfe3feed4a7ba7decf@haskell.org> References: <044.b09c2294dcb548cfe3feed4a7ba7decf@haskell.org> Message-ID: <059.fa337d5cab602d6ad626c0ed246c35d3@haskell.org> #8398: reify module list in TH -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: 1480 Type of failure: | Related Tickets: #8337 None/Unknown | Test Case: | Blocking: 7867 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This ticket is mentioned on [wiki:TemplateHaskell/Annotations]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 21:20:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 21:20:48 -0000 Subject: [GHC] #8438: Validation failure compiling primitive-memops.c In-Reply-To: <047.531102d80c106049f501fc03b8c458e2@haskell.org> References: <047.531102d80c106049f501fc03b8c458e2@haskell.org> Message-ID: <062.85c3f75509ec4816f1d59f40c7c527f9@haskell.org> #8438: Validation failure compiling primitive-memops.c -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: None/Unknown => Building GHC failed * component: Compiler => Build System * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 02:41:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 02:41:33 -0000 Subject: [GHC] #9368: Add strictly accumulating scanl' to Data.List In-Reply-To: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> References: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> Message-ID: <060.eec02e1e7ba2c4bfe6ce2782a00570fe@haskell.org> #9368: Add strictly accumulating scanl' to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9345 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D498 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D498 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 23:14:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 23:14:51 -0000 Subject: [GHC] #9808: Add data-dir to InstalledPackageInfo In-Reply-To: <044.d7df9b805388be68f8a820b34b606910@haskell.org> References: <044.d7df9b805388be68f8a820b34b606910@haskell.org> Message-ID: <059.48f3cd72a5fda76157b9c1bf3dcacd26@haskell.org> #9808: Add data-dir to InstalledPackageInfo -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): The required change, that adds the `data-dir` field to `InstalledPackageInfo` is now in upstream Cabal, but since I don't have commit access to the Cabal submodule repo that GHC is using, I have no idea how to make this revision available to `arc diff`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 01:40:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 01:40:13 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma In-Reply-To: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> References: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> Message-ID: <062.862c95fb560811b9305627b4d0262bbd@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 23:19:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 23:19:17 -0000 Subject: [GHC] #8294: T7478 fails on Mac OS X with "unexpected bindingNone" from ld In-Reply-To: <045.23eeb39c8ca5a8c2bf9f89559cb4fa68@haskell.org> References: <045.23eeb39c8ca5a8c2bf9f89559cb4fa68@haskell.org> Message-ID: <060.1b92bc86ea019ea4f2ad91005ff6402b@haskell.org> #8294: T7478 fails on Mac OS X with "unexpected bindingNone" from ld -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.7 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: T7478 | Related Tickets: #7478 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #7478 Comment: This is a duplicate of #7478 itself, since it has been re-opened. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 23:16:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 23:16:05 -0000 Subject: [GHC] #8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld In-Reply-To: <047.84247404c5743a6b21344dd8163dc5f7@haskell.org> References: <047.84247404c5743a6b21344dd8163dc5f7@haskell.org> Message-ID: <062.209e44556367a4421e5e859984b0759a@haskell.org> #8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld ---------------------------------------+--------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.7 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7478 Differential Revisions: | ---------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: #8294 => #7478 Comment: This is a duplicate of #7478 itself, since it has been removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 23:22:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 23:22:00 -0000 Subject: [GHC] #8388: forall on non-* types In-Reply-To: <047.f92d46972e6180e14068208ce6b24ecd@haskell.org> References: <047.f92d46972e6180e14068208ce6b24ecd@haskell.org> Message-ID: <062.6f4a5e7e400306e1674a41cc34ba2e4b@haskell.org> #8388: forall on non-* types -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 22:19:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 22:19:28 -0000 Subject: [GHC] #8424: quasi-quotes have carriage returns on Windows In-Reply-To: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> References: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> Message-ID: <063.3ef7fa83963eb3c51f09621af5041abe@haskell.org> #8424: quasi-quotes have carriage returns on Windows -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.6.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: gintas (added) * os: Unknown/Multiple => Windows Comment: While cleaning up [https://github.com/ghc/ghc/blob/64c9898f7b5239435f131f5444d62bda23dfc9ef/compiler/parser/Lexer.x#L110 Lexer.x] a few months ago, I tried to change: {{{ $white_no_nl = $whitechar # \n }}} To: {{{ $white_no_nl = $whitechar # $nl }}} That didn't validate, and I didn't quite understand what was going on, so I left it at that. I did add a TODO, because I thought it might be related to this ticket. To whomever fixes this bug: please also remove that TODO, especially if that line turns out to be fine the way it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 23:29:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 23:29:05 -0000 Subject: [GHC] #8372: enable -dcmm-lint by default for .cmm input files In-Reply-To: <047.2bed277bea58db09fd49b004bc79ac5f@haskell.org> References: <047.2bed277bea58db09fd49b004bc79ac5f@haskell.org> Message-ID: <062.779dcf1b58b02bad7e3c4e3f31a302ef@haskell.org> #8372: enable -dcmm-lint by default for .cmm input files -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): For reference, in `rts/ghc.mk` we do have: {{{ # We *want* type-checking of hand-written cmm. rts_HC_OPTS += -dcmm-lint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 19:58:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 19:58:51 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.3fb39eb2e917b0d3a562158846b02c67@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: 9766 Unknown/Multiple | Related Tickets: #8778 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 22:25:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 22:25:21 -0000 Subject: [GHC] #8420: Spurious dynamic library dependencies In-Reply-To: <053.6d20c8a5a1dda98693fe4739c5ec23a3@haskell.org> References: <053.6d20c8a5a1dda98693fe4739c5ec23a3@haskell.org> Message-ID: <068.25aad130953e33ca609d91e3856eff56@haskell.org> #8420: Spurious dynamic library dependencies -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * component: Compiler => Driver -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 22:30:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 22:30:12 -0000 Subject: [GHC] #8419: add rawSystem variant that takes an environment In-Reply-To: <044.1336ed0d15ff978db053dbcdcdc7efa1@haskell.org> References: <044.1336ed0d15ff978db053dbcdcdc7efa1@haskell.org> Message-ID: <059.26e3bdbb5a47b97c27b727821f8ff1f2@haskell.org> #8419: add rawSystem variant that takes an environment -------------------------------------+------------------------------------- Reporter: dagit | Owner: ekmett Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: invalid | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => invalid Comment: The change you are requesting has to go through the [https://www.haskell.org/haskellwiki/Library_submissions library submission process] first (basically send an email to libraries at haskell.org). Please re-open this ticket when your proposal gets accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 21:19:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 21:19:12 -0000 Subject: [GHC] #8447: A combination of type-level comparison and subtraction does not work for 0 In-Reply-To: <045.29509d9558ae25a4e3d08d5efb0d4522@haskell.org> References: <045.29509d9558ae25a4e3d08d5efb0d4522@haskell.org> Message-ID: <060.2b750e983c282cf59bd313cef04eadc2@haskell.org> #8447: A combination of type-level comparison and subtraction does not work for 0 -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: nushio: could you please attach a testcase for the testsuite. The github link you posted seems to be missing some pieces. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 21:50:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 21:50:48 -0000 Subject: [GHC] #5364: Access RTS flag values from inside Haskell programs In-Reply-To: <045.dac6fe30423f96742744c66f751179f8@haskell.org> References: <045.dac6fe30423f96742744c66f751179f8@haskell.org> Message-ID: <060.3663f4070418d18615abec96fdfbc530@haskell.org> #5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * differential: => Phab:D306 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 03:09:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 03:09:17 -0000 Subject: [GHC] #9807: Only test for bug #9439 when llvm is installed (was: Clarify warning if LLVM is not found by configure) In-Reply-To: <049.ad5e3d70fc50bb323fb6edb8157fac2f@haskell.org> References: <049.ad5e3d70fc50bb323fb6edb8157fac2f@haskell.org> Message-ID: <064.c6d7d4ae74c4be42c17490cf239f4f2a@haskell.org> #9807: Only test for bug #9439 when llvm is installed -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: Phab:D500 | -------------------------------------+------------------------------------- Changes (by thomie): * failure: Documentation bug => Other * differential: => Phab:D500 Comment: Thanks for the report. A patch is up for review. It will now just show: {{{ checking for llc... no checking for opt... no }}} or {{{ checking for llc... yes checking for opt... yes checking whether bootstrap compiler is affected by bug 9439... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 22:39:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 22:39:46 -0000 Subject: [GHC] #8415: GHC bug using darcs on Kubuntu 13.04 In-Reply-To: <050.0cd78a7f5d73080db989012caf89186c@haskell.org> References: <050.0cd78a7f5d73080db989012caf89186c@haskell.org> Message-ID: <065.7792ea24d470dca520343d98f0796605@haskell.org> #8415: GHC bug using darcs on Kubuntu 13.04 -------------------------------------+------------------------------------- Reporter: | Owner: simonmar JoeAquilina | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: worksforme | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Thank you for the report. A lot has changed since you opened it though, so I'm going to close this ticket for now. If you do experience ghc panics in relation to darcs again, don't hesitate to re-open. Please try to describe the steps necessary for us to reproduce the problem, see [wiki:ReportABug]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 21:28:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 21:28:32 -0000 Subject: [GHC] #8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported In-Reply-To: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> References: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> Message-ID: <059.1dc68eaa035e1e297183d135c96ab886@haskell.org> #8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: fixed | Architecture: powerpc64 Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: None/Unknown => Building GHC failed * component: Compiler => Build System * resolution: => fixed Comment: Replying to [comment:2 rwbarton]: > Ideally, you would output a `__builtin_prefetch` call where `rw` is 0, `locality` is the argument of the `MO_Prefetch_Data` constructor, and `addr` comes from the `args` field of the `CmmUnsafeForeignCall`. That looks pretty easy to do, by adding another special case for `fn_addr` and sending `MO_Prefetch_Data _` to `__builtin_prefetch` in `pprCallishMachOp_for_C`. Please open a new task ticket if that is still needed. Commit 896cee02e766c687a52cd75382bcfed64a623619 should have fixed the powerpc64 build, so I'm closing this ticket if you agree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 03:19:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 03:19:24 -0000 Subject: [GHC] #9744: Make program name and project version configurable In-Reply-To: <044.83253224e4144ae46fadcfbf6a5cd378@haskell.org> References: <044.83253224e4144ae46fadcfbf6a5cd378@haskell.org> Message-ID: <059.71fadfc537bf2b94710e4618f1ee83b2@haskell.org> #9744: Make program name and project version configurable -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D496 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D496 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 03:18:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 03:18:24 -0000 Subject: [GHC] #9808: Add data-dir to InstalledPackageInfo In-Reply-To: <044.d7df9b805388be68f8a820b34b606910@haskell.org> References: <044.d7df9b805388be68f8a820b34b606910@haskell.org> Message-ID: <059.05e1b2a9491fa6676d2de2d823bfb8af@haskell.org> #9808: Add data-dir to InstalledPackageInfo -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Package | Version: 7.8.3 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D499 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D499 * component: Compiler => Package system -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 05:49:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 05:49:40 -0000 Subject: [GHC] #9808: Add data-dir to InstalledPackageInfo In-Reply-To: <044.d7df9b805388be68f8a820b34b606910@haskell.org> References: <044.d7df9b805388be68f8a820b34b606910@haskell.org> Message-ID: <059.8c682a3f9fdd44fc89c9f780f27b6ed6@haskell.org> #9808: Add data-dir to InstalledPackageInfo -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Package | Version: 7.8.3 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D499 | -------------------------------------+------------------------------------- Comment (by luite): turned out to be not too hard after all, after thomie told me that the git.haskell.org/packages/Cabal.git is automatically mirrored from github :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 03:25:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 03:25:01 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.e3e1457bc8f6b26e12a597ed4a5b4119@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: infoneeded Type: feature | Milestone: 7.10.1 request | Version: 7.6.3 Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: Sorry I missed this Iceland_Jack, can you rebase this patch? I don't think it applies on HEAD anymore I'm afraid (but I may have missed something). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 21:32:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 21:32:00 -0000 Subject: [GHC] #3827: Compiling fails on linux-powerpc In-Reply-To: <050.513cd5a1d672cd1796d29f3e29565e48@haskell.org> References: <050.513cd5a1d672cd1796d29f3e29565e48@haskell.org> Message-ID: <065.591d1a9dad3529e247c979aa21a535a5@haskell.org> #3827: Compiling fails on linux-powerpc ----------------------------------------------+--------------------------- Reporter: speleologic | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: Build System | Version: 6.12.1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * component: Compiler => Build System * resolution: => worksforme Comment: Closing this 5 year old ticket. Probably a lot has change since then, and #8437 leads me to believe the powerpc build actually worked quite recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 22:45:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 22:45:12 -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.7cc0df189f059334e27d7c84075e0e25@haskell.org> #8406: Invalid object in isRetainer() or Segfault -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: Compiler => Runtime System Comment: crockeea: could you try to compile your program with 7.8.3? Without a testcase it's hard to do anything. Should we keep this ticket open? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 03:22:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 03:22:42 -0000 Subject: [GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs In-Reply-To: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> References: <051.1c38a1e6c743f17158ef37805e71fa91@haskell.org> Message-ID: <066.783c62f7777baae0501093e0c87f0dc1@haskell.org> #9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: InstanceSigs (Type checker) | TypeFamilies Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded * milestone: => 7.10.1 Comment: Before we merge this, lets move it out of patch state until it's ready. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 05:51:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 05:51:40 -0000 Subject: [GHC] #9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook In-Reply-To: <044.0e39eba5e5bc320ab7bb45f4a7f2c823@haskell.org> References: <044.0e39eba5e5bc320ab7bb45f4a7f2c823@haskell.org> Message-ID: <059.077a7e14de7384bed5fcf066bd8f58c0@haskell.org> #9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D501 | -------------------------------------+------------------------------------- Changes (by luite): * differential: => Phab:D501 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 20:27:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 20:27:37 -0000 Subject: [GHC] #8442: Cabal-install internal error with any use In-Reply-To: <043.647995df1e92d2ba03fcc0642ce966a9@haskell.org> References: <043.647995df1e92d2ba03fcc0642ce966a9@haskell.org> Message-ID: <058.d13850079ebcaebc10beb16f05888378@haskell.org> #8442: Cabal-install internal error with any use -------------------------------------+------------------------------------- Reporter: senk | Owner: pgj Type: bug | Status: closed Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: Resolution: worksforme | Architecture: x86_64 (amd64) Operating System: FreeBSD | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Since this error is exactly the same as the one in #8013, and that issue was closed 4 months ago mentioning "... haven't had a reoccurrence of the problem since.", I'm closing this one as well. senk: please re-open if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 00:45:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 00:45:49 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.70f77ae2af3a0bd8bf95f2148bf915af@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dredozubov): I've added a simple type to restrict sse versions to major ones and 4.2(it's the only not *.0 version that've been explicitly checked in sources afaik). I'm not so sure if the naming is right on. > A direct consequence of above definition is that bash command-line auto- completion does not suggest -msse4.2 flag. Probably it will work better with --show-options if separate flags will be used(such as -msse2/-msse4 etc). Please advice and don't bash me too hard, it's my first attempt to work with ghc. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 22:52:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 22:52:14 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.1cbb080deca03b204a97b922e07dace6@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8404 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 18 22:51:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Nov 2014 22:51:56 -0000 Subject: [GHC] #8404: Default to turning on architecture specific optimizations in the codegen In-Reply-To: <044.264de95b52ceed5babd88d22128d25c7@haskell.org> References: <044.264de95b52ceed5babd88d22128d25c7@haskell.org> Message-ID: <059.2accea333472b830485b5627b4ed18ac@haskell.org> #8404: Default to turning on architecture specific optimizations in the codegen -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: (NCG) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * failure: None/Unknown => Runtime performance bug * component: Compiler => Compiler (NCG) * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 06:05:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 06:05:45 -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.a29dd3193baf2333ec4a645c2d971404@haskell.org> #8406: Invalid object in isRetainer() or Segfault -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): I won't be able to come up with an testcase anymore. My guess is that there was (is?) a problem with -hr and multithreading, but I no longer have the code and the problem does not occur in 7.8.3 with a simple single-threaded example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 06:22:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 06:22:55 -0000 Subject: [GHC] #9736: Constant folding rules are wrong for GHCJS In-Reply-To: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> References: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> Message-ID: <059.07b19b6e93b797a68aad3150bbd2bb20@haskell.org> #9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): I've made the `removeOp32` operation target word size dependent (from `DynFlags`) and `rightShiftLogical` use a correctly sized word for the target. I'm not 100% sure what's the best way to do `removeOp32` for GHCJS, since `ArchJavaScript` has to be treated as 32 bit (that's the only word size available for bitwise operations), but numbers can have a bigger range. In most cases, the primops already handle truncation, and the dataflow analysis in the optimizer removes the superfluous narrowing operations. In some situations, narrowing is still needed, for example when a value is obtained from a foreign operation. Since most `NarrowInt32` operations are actually unnecessary for GHCJS, and I'm not sure how well the optimizer will be able to strip the `NarrowInt32Op` from for example `Int32` operations, I'm not adding an exception for `ArchJavaScript` in `removeOp32` and deal with exceptional situations like foreign return values individually in the desugarer. If it turns out that there are situations that can't be handled this way, I'll send another change request for that, like below: {{{#!hs removeOp32 :: RuleM CoreExpr removeOp32 = do dflags <- getDynFlags if wordSizeInBits dflags == 32 && -- JavaScript has 32 bit bitwise operations -- but numbers have a greater range platformArch (targetPlatform dflags) /= ArchJavaScript then do [e] <- getArgs return e else mzero }}} (and unfortunately I'd have to copy/paste the whole PrelRules module into GHCJS again if I'm too late) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 06:26:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 06:26:49 -0000 Subject: [GHC] #9736: Constant folding rules are wrong for GHCJS In-Reply-To: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> References: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> Message-ID: <059.b55da8f08c560a5cf8434e38dc51b8f4@haskell.org> #9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D502 | -------------------------------------+------------------------------------- Changes (by luite): * differential: => Phab:D502 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 08:24:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 08:24:24 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.d4b287f59d89abcb17c069cab6e0eac9@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): I commented on the Phab revision. That's a good start :-) Oh, and when you upload a Phab revision you should fill in the appropriate field in the Trac ticket. BTW. I'm surprised that the changes don't go outside of DynFlags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 10:02:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 10:02:57 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.1dca3466b45f9158a79f3937edc510ef@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"42244668af6d8c1dd6a2d64af90ed57d8ecd8d88/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="42244668af6d8c1dd6a2d64af90ed57d8ecd8d88" Reimplement im/export primitives for integer-gmp2 The import/export operations were available in `integer-gmp-0.5.1` already, but need to be reimplemented from scratch for the `integer-gmp-1.0.0` rewrite. This also adds a few more operations than were previously available for use w/ the `BigNat` type (which will be useful for implementing serialisation for the upcoming `Natural` type) Specifically, the following operations are (re)added (albeit with slightly different type-signatures): - `sizeInBaseBigNat` - `sizeInBaseInteger` - `sizeInBaseWord#` - `exportBigNatToAddr` - `exportIntegerToAddr` - `exportWordToAddr` - `exportBigNatToMutableByteArray` - `exportIntegerToMutableByteArray` - `exportWordToMutableByteArray` - `importBigNatFromAddr` - `importIntegerFromAddr` - `importBigNatFromByteArray` - `importIntegerFromByteArray` NOTE: The `integerGmpInternals` test-case is updated but not yet re-enabled as it contains tests for other primitives which aren't yet reimplemented. This addresses #9281 Reviewed By: austin, duncan Differential Revision: https://phabricator.haskell.org/D480 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 10:06:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 10:06:51 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.5491d3c9d4425282a8c637598f8bf59d@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: 9766 Unknown/Multiple | Related Tickets: #8778 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): #9766 is now ready for review. If it all goes well, then this patch can be merged straight after. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 11:00:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 11:00:09 -0000 Subject: [GHC] #9776: -frule-check flag not recognized without parameter In-Reply-To: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> References: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> Message-ID: <063.3aae42dd036fe6e02777f44825a48acb@haskell.org> #9776: -frule-check flag not recognized without parameter -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: carlostome Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) warning at compile-time | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carlostome): * owner: => carlostome -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 11:13:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 11:13:45 -0000 Subject: [GHC] #9810: encodeFloat 1 2047 = -1024.0 In-Reply-To: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> References: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> Message-ID: <059.e58cea31fa212176c9e640580342176f@haskell.org> #9810: encodeFloat 1 2047 = -1024.0 -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: ieee Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9811 Test Case: | Blocking: | Differential Revisions: Phab:D486 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"e2af452cd533778c5447719c59429d72bb1fe00d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e2af452cd533778c5447719c59429d72bb1fe00d" Restore exact old semantics of `decodeFloat` `integer-gmp2` uses the new 64bit-based IEEE deconstructing primop introduced in b62bd5ecf3be421778e4835010b6b334e95c5a56. However, the returned values differ for exceptional IEEE values: Previous (expected) semantics: > decodeFloat (-1/0) (-4503599627370496,972) > decodeFloat (1/0) (4503599627370496,972) > decodeFloat (0/0) (-6755399441055744,972) Currently (broken) semantics: > decodeFloat (-1/0 :: Double) (-9223372036854775808,-53) > decodeFloat (1/0 :: Double) (-9223372036854775808,-53) > decodeFloat (0/0 :: Double) (-9223372036854775808,-53) This patch reverts to the old expected semantics. I plan to revisit the implementation during GHC 7.11 development. This should address #9810 Reviewed By: austin, ekmett, luite Differential Revision: https://phabricator.haskell.org/D486 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 11:20:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 11:20:37 -0000 Subject: [GHC] #9810: encodeFloat 1 2047 = -1024.0 In-Reply-To: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> References: <044.30755e680d4008d346942fefa4a64bbb@haskell.org> Message-ID: <059.129eb055053d109e36757066624f22bf@haskell.org> #9810: encodeFloat 1 2047 = -1024.0 -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: ieee Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9811 Test Case: | Blocking: | Differential Revisions: Phab:D486 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 12:29:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 12:29:00 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.bccd57aec0a49f0e41658d9d3448506f@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: Phab:D497 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D497 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 13:04:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 13:04:31 -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.636a58ce2892c1241e64a4a23b4d6e1b@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Similarly, `-dverbose-core2core` prints some information on stdout and some on stderr. This could also be cleaned up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 16:07:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 16:07:29 -0000 Subject: [GHC] #9776: -frule-check flag not recognized without parameter In-Reply-To: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> References: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> Message-ID: <063.b12d594c74328475c27754ac9e9ab09d@haskell.org> #9776: -frule-check flag not recognized without parameter -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: carlostome Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) warning at compile-time | Blocked By: Test Case: T9776 | Related Tickets: Blocking: | Differential Revisions: Phab:D503 | -------------------------------------+------------------------------------- Changes (by carlostome): * testcase: => T9776 * differential: => Phab:D503 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 16:15:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 16:15:07 -0000 Subject: [GHC] #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` Message-ID: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As part of my work on #6018 I added new fields to `SynTyCon` data constructor of `TyCon` type. These fields only make sense for type families because we don't trace injectivity information for type synonyms. `SynTyCon` already has some fields that only make sense for type families. Richard suggests that `SynTyCon` is split into two separate constructors. With my implementation of injective type families this makes even more changes. I'm going to make that change in HEAD Real Soon Now so that I can rebase my work on top of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 18:38:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 18:38:16 -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.e80a1a35d5e828af71d4678adc9ac13e@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: new Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => new Comment: Needs work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 18:41:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 18:41: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.61d291c8fc9e446df3a0c2a0040a3316@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: new Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): @david, unless theres benchmarks showing a substantial difference, probably doesnt matter @thomie, why's it (re)marked new? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 18:46:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 18:46:02 -0000 Subject: [GHC] #9776: -frule-check flag not recognized without parameter In-Reply-To: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> References: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> Message-ID: <063.58069d9066719ee272f61a57e515b8b7@haskell.org> #9776: -frule-check flag not recognized without parameter -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: carlostome Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) warning at compile-time | Blocked By: Test Case: T9776 | Related Tickets: Blocking: | Differential Revisions: Phab:D503 | -------------------------------------+------------------------------------- Changes (by carlostome): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 18:48:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 18:48:18 -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.88882c23cc276673f93eedab75d03dc2@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: new Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Prelude | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Because it broke validate, see comment:33. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 19:14:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 19:14:25 -0000 Subject: [GHC] #8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim In-Reply-To: <044.267bff412f23f7b08ec60f95b7390d6c@haskell.org> References: <044.267bff412f23f7b08ec60f95b7390d6c@haskell.org> Message-ID: <059.fcddf4bd2b46e1ddfaa0e90d47d34764@haskell.org> #8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim -------------------------------------+------------------------------------- Reporter: guest | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: ghc-prim Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: dfeuer, core-libraries-committee@? (added) Comment: In commit 4c03791f986509c5d95adf50de555876ed05522e (libraries/ghc- prim/GHC/Classes.hs): {{{ Author: Simon Peyton Jones <> Date: Mon May 12 10:53:09 2014 +0100 Specialise Eq, Ord, Read, Show at Int, Char, String These instances are quite common, so it's good to have pre-specialised versions available }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 19:27:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 19:27:15 -0000 Subject: [GHC] #8353: Easy way to defer type errors In-Reply-To: <047.34842edf8c636f9b11361128b151d960@haskell.org> References: <047.34842edf8c636f9b11361128b151d960@haskell.org> Message-ID: <062.cce036b64614959b709aa447996d4c06@haskell.org> #8353: Easy way to defer type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) Comment: Can you explain the "joy" of using '-fdefer-type-errors'? What is the intention of this ticket? Once #9497 is fixed, there will also be '-fdefer-typed-holes'. Would that change this ticket in any way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 19:31:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 19:31:54 -0000 Subject: [GHC] #8346: Rank 1 type signature still requires RankNTypes In-Reply-To: <049.38c02589d1bbe9e0e53bb31c4e45e3ed@haskell.org> References: <049.38c02589d1bbe9e0e53bb31c4e45e3ed@haskell.org> Message-ID: <064.abf7efbf9b0b37eee0808773dc4cc7d3@haskell.org> #8346: Rank 1 type signature still requires RankNTypes -------------------------------------+------------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #2605 rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 19:42:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 19:42:11 -0000 Subject: [GHC] #8327: Cmm sinking does not eliminate dead code in loops In-Reply-To: <048.db1f76a3cb62b60bb69e968bf8de2551@haskell.org> References: <048.db1f76a3cb62b60bb69e968bf8de2551@haskell.org> Message-ID: <063.f761451f917c9f7b287b458b2fb65f6d@haskell.org> #8327: Cmm sinking does not eliminate dead code in loops -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * failure: None/Unknown => Runtime performance bug * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 19:43:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 19:43:41 -0000 Subject: [GHC] #8336: Sinking pass could optimize some assignments better In-Reply-To: <048.947d9151e47af3b2a32fe6bc1e763542@haskell.org> References: <048.947d9151e47af3b2a32fe6bc1e763542@haskell.org> Message-ID: <063.d248dd814ad774614ca6017c1b229e7f@haskell.org> #8336: Sinking pass could optimize some assignments better -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 19:44:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 19:44:00 -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.13d2c21ff52a88ac656892636e160bc0@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: carlostome Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carlostome): * owner: => carlostome -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 19:56:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 19:56:29 -0000 Subject: [GHC] #8332: hp2ps does not escape parentheses In-Reply-To: <044.c4542af34cc7ec300ffef7e02b78e741@haskell.org> References: <044.c4542af34cc7ec300ffef7e02b78e741@haskell.org> Message-ID: <059.0aa46bfde0b3d68793ff3f3e7a7a7067@haskell.org> #8332: hp2ps does not escape parentheses -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: luite: can you attach an example program that demonstrates the problem. Note, in `utils/hp2ps/CHANGES`: {{{ When generating PostScript to show strings, '(' and ')' may need to be escaped. These characters are now escaped when the JOB string is shown. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 20:01:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 20:01:33 -0000 Subject: [GHC] #8324: ghci failed on startup In-Reply-To: <047.dbaa00e85fab329e799a96ad7710b0f9@haskell.org> References: <047.dbaa00e85fab329e799a96ad7710b0f9@haskell.org> Message-ID: <062.8f2f2e8605f9db7a0ac0f19169837fa3@haskell.org> #8324: ghci failed on startup -------------------------------------+------------------------------------ Reporter: dabraham | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Changes (by thomie): * cc: hvr (added) * status: new => closed * resolution: => worksforme Comment: Using version 7.8.3, ghci should work on Mac. Please re-open if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 20:06:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 20:06:37 -0000 Subject: [GHC] #8323: explore ways to possibly use more tag bits in x86_64 pointers In-Reply-To: <045.7af99787c601e4e730a6e29b769c14e5@haskell.org> References: <045.7af99787c601e4e730a6e29b769c14e5@haskell.org> Message-ID: <060.8952c2c97ff2fed578c1bcc443604784@haskell.org> #8323: explore ways to possibly use more tag bits in x86_64 pointers -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Could you expand the description a bit. What are the possible use cases of those extra bits? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 20:09:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 20:09:01 -0000 Subject: [GHC] #8321: improve basic block layout on LLVM backend by predicting stack/heap checks In-Reply-To: <047.6404a13417433923604862bc63a62420@haskell.org> References: <047.6404a13417433923604862bc63a62420@haskell.org> Message-ID: <062.1d6dbd07f8c5e4b8f70ca34e46037b53@haskell.org> #8321: improve basic block layout on LLVM backend by predicting stack/heap checks -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: (LLVM) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 20:34:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 20:34:31 -0000 Subject: [GHC] #8319: Simplifier ticks exhausted (need -fsimpl-tick-factor=955) In-Reply-To: <047.52cf735ac7af61618a42a5746ffd4202@haskell.org> References: <047.52cf735ac7af61618a42a5746ffd4202@haskell.org> Message-ID: <062.c35ae6e7510f01f9d2c62f1da3909826@haskell.org> #8319: Simplifier ticks exhausted (need -fsimpl-tick-factor=955) -------------------------------------+------------------------------------- Reporter: ruudkoot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This code compiles with `ghc-7.8.1`, `ghc-7.8.3` and `ghc-7.9.20141115`, using `-O2`. Should a regression test be added? Note that the code imports `QuickCheck`. Without it, the bug is not triggered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 20:44:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 20:44:07 -0000 Subject: [GHC] #8318: GHC does not infer type of `tagToEnum#` expression In-Reply-To: <048.ec88b096ee125380632b6d2dee0264c0@haskell.org> References: <048.ec88b096ee125380632b6d2dee0264c0@haskell.org> Message-ID: <063.884da18fbb67ef2b1926adab74a4cc33@haskell.org> #8318: GHC does not infer type of `tagToEnum#` expression -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) Comment: The error message for the code from the description is improved using ghc HEAD. A regression test should be added. {{{ $ ghc-7.9.20141115 test.hs [1 of 1] Compiling TTE ( test.hs, test.o ) test.hs:6:10: Bad call to tagToEnum# at type r_alE Specify the type by giving a type signature e.g. (tagToEnum# x) :: Bool In the expression: tagToEnum# 1# In the expression: case tagToEnum# 1# of { True -> "True" False -> "False" } In an equation for ?f?: f = case tagToEnum# 1# of { True -> "True" False -> "False" } }}} See also commit 706c439fb5d3f1e30ad7b3953fde17dd01dae1bc: {{{ Author: simonpj Date: Wed Aug 16 20:30:23 2006 +0000 Add test for tagToEnum# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 20:48:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 20:48:04 -0000 Subject: [GHC] #8316: GHCi debugger segfaults when trying force a certain variable In-Reply-To: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> References: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> Message-ID: <059.200ad8f7eb6a6b660b4666eeb97f5753@haskell.org> #8316: GHCi debugger segfaults when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) Comment: Confirmed on Linux x86_64 with ghc-7.9.20141115. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 21:05:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 21:05:26 -0000 Subject: [GHC] #8313: Poor performance of higher-order functions with unboxing In-Reply-To: <044.b6968c03bf741916b66e492dab74ef19@haskell.org> References: <044.b6968c03bf741916b66e492dab74ef19@haskell.org> Message-ID: <059.21ed6154ee6ce836fd1f097e57ac7084@haskell.org> #8313: Poor performance of higher-order functions with unboxing -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.6.3 Resolution: | Keywords: slow unboxed Operating System: | higher order Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Easy (less than 1 performance bug | hour) Test Case: | Blocked By: 6084 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): After compiling the program from comment:4 with `-O2`, `manual` is now 4x faster. {{{ $ ghc-7.8.3 -O2 T8313.hs $ ./T8313 manual +RTS -t (33333333,33333334,33333334) <> $ ./T8313 auto +RTS -t (33333333,33333334,33333334) <> }}} Same results with `ghc-7.9.20141115`. Still needs that performance test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 21:11:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 21:11:10 -0000 Subject: [GHC] #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) In-Reply-To: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> References: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> Message-ID: <062.60fe331e37da2cafe9f5eb0dfd93c3d0@haskell.org> #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Keywords: (NCG) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #5615 Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug * related: #9188 => #5615 Comment: #9188 was closed as a duplicate of #5615. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 21:11:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 21:11:20 -0000 Subject: [GHC] #8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim In-Reply-To: <044.267bff412f23f7b08ec60f95b7390d6c@haskell.org> References: <044.267bff412f23f7b08ec60f95b7390d6c@haskell.org> Message-ID: <059.55c0ade8e8683eb49eb427748945da37@haskell.org> #8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim -------------------------------------+------------------------------------- Reporter: guest | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: ghc-prim Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm wondering if we should revert the `Eq` and `Ord` specialization for `String` and instead try to have some fun with fusion, doing something much like what we do with `foldr2`. If I'm not mistaken, {{{#!hs xs == ys = foldr go null xs ys where go _x _r [] = False go x r (z:zs) | x == z = r zs | otherwise = False }}} {{{#!hs compare xs ys = foldr go (bool LT EQ . null) xs ys where go _x _r [] = GT go x r (z:zs) = case compare x z of LT -> LT GT -> GT EQ -> r zs }}} and similarly (carefully) reversing the roles of `xs` and `ys`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 21:28:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 21:28:52 -0000 Subject: [GHC] #8310: Can we change the semantics of `Trustworthy`? In-Reply-To: <045.91a9ef38d8b695a957254547374ae4ed@haskell.org> References: <045.91a9ef38d8b695a957254547374ae4ed@haskell.org> Message-ID: <060.96f4c4c384b670e050d359a01d061347@haskell.org> #8310: Can we change the semantics of `Trustworthy`? -------------------------------------+------------------------------------- Reporter: ekmett | Owner: dterei Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): I saw some Trustworthy changes fly by, maybe this is fixed as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 21:42:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 21:42:07 -0000 Subject: [GHC] #9813: Error when reifying type constructor Message-ID: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code works under ghc-7.6.3 and template-haskell-2.8.0.0: {{{#!hs {-# LANGUAGE TemplateHaskell #-} data Huh = ThisDefinitely | UsedToWork constructorNames :: String constructorNames = $(do ty <- reify ''Huh let showCon (NormalC n _) = nameBase n strs = case ty of (TyConI (DataD _ _ _ cons _)) -> map showCon cons return . LitE . StringL $ concat strs) main = putStrLn constructorNames }}} Printing the following at compile time: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Linking Main ... }}} and then successfully executing: {{{ $ ./Main ThisDefinitelyUsedToWork }}} However, using ghc 7.8.3/template-haskell-2.9.0.0 I get the following compile error: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Main.hs:8:22: ?Huh? is not in the type environment at a reify In the splice: $(do { ty <- reify ''Huh; let showCon (NormalC n _) = ... ....; return . LitE . StringL $ concat strs }) }}} Is this expected? I couldn't see anything in the GHC release notes to suggest this should no longer work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 21:44:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 21:44:12 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.a83868deea7128ae497f5572d65666b3@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by owst: Old description: > The following code works under ghc-7.6.3 and template-haskell-2.8.0.0: > > {{{#!hs > {-# LANGUAGE TemplateHaskell #-} > > data Huh = ThisDefinitely > | UsedToWork > > constructorNames :: String > constructorNames = $(do > ty <- reify ''Huh > let showCon (NormalC n _) = nameBase n > strs = case ty of > (TyConI (DataD _ _ _ cons _)) -> map showCon cons > return . LitE . StringL $ concat strs) > > main = putStrLn constructorNames > }}} > > Printing the following at compile time: > > {{{ > [1 of 1] Compiling Main ( Main.hs, Main.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package array-0.4.0.1 ... linking ... done. > Loading package deepseq-1.3.0.1 ... linking ... done. > Loading package containers-0.5.0.0 ... linking ... done. > Loading package pretty-1.1.1.0 ... linking ... done. > Loading package template-haskell ... linking ... done. > Linking Main ... > }}} > > and then successfully executing: > > {{{ > $ ./Main > ThisDefinitelyUsedToWork > }}} > > However, using ghc 7.8.3/template-haskell-2.9.0.0 I get the following > compile error: > {{{ > [1 of 1] Compiling Main ( Main.hs, Main.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package array-0.5.0.0 ... linking ... done. > Loading package deepseq-1.3.0.2 ... linking ... done. > Loading package containers-0.5.5.1 ... linking ... done. > Loading package pretty-1.1.1.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > > Main.hs:8:22: > ?Huh? is not in the type environment at a reify > In the splice: > $(do { ty <- reify ''Huh; > let showCon (NormalC n _) = ... > ....; > return . LitE . StringL $ concat strs }) > }}} > > Is this expected? I couldn't see anything in the GHC release notes to > suggest this should no longer work. New description: The following code works under ghc-7.6.3 and template-haskell-2.8.0.0: {{{#!hs {-# LANGUAGE TemplateHaskell #-} data Huh = ThisDefinitely | UsedToWork constructorNames :: String constructorNames = $(do ty <- reify ''Huh let strs = case ty of (TyConI (DataD _ _ _ cons _)) -> map showCon cons showCon (NormalC n _) = nameBase n return . LitE . StringL $ concat strs) main = putStrLn constructorNames }}} Printing the following at compile time: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Linking Main ... }}} and then successfully executing: {{{ $ ./Main ThisDefinitelyUsedToWork }}} However, using ghc 7.8.3/template-haskell-2.9.0.0 I get the following compile error: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Main.hs:8:22: ?Huh? is not in the type environment at a reify In the splice: $(do { ty <- reify ''Huh; let showCon (NormalC n _) = ... ....; return . LitE . StringL $ concat strs }) }}} Is this expected? I couldn't see anything in the GHC release notes to suggest this should no longer work. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 22:07:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 22:07:24 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.5e724447a8e4e816d1811d58a8b9957a@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D452 | -------------------------------------+------------------------------------- Comment (by rodlogic): After a some time getting my feet wet with the Lexer.x and Parser.y, I am coming to the conclusion that this is not a trivial change and involves more changes to the parser than I would like to or am able to handle at this point. I also noticed that #8822 may also be stuck based on the same/similar difficulty. The difficulty in debugging the parser and the somewhat long change/compile cycles also don't help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 22:14:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 22:14:49 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.ccd1586e5c798582a36fb9eb990e62d4@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D488 => Phab:D488 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 22:40:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 22:40:53 -0000 Subject: [GHC] #8353: Easy way to defer type errors In-Reply-To: <047.34842edf8c636f9b11361128b151d960@haskell.org> References: <047.34842edf8c636f9b11361128b151d960@haskell.org> Message-ID: <062.7384e8b79bafcf29306fa8b37c818cb0@haskell.org> #8353: Easy way to defer type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer Comment: Though I originally encountered my desire for this feature in a teaching setting, it happens in my own work, too. Say I have a big file with lots of definitions. Somewhere, there is a type error. To fix the type error, I need to check the types of other definitions in my file. But, I can't use GHCi to query my definitions, because the file has a type error. Urgh. So, today, I have to enable `-fdefer-type-errors`, load the file, see my type ''warnings'', and then query the definitions I need to fix everything up. A big annoyance of this workflow is that, now, `-fdefer-type-errors` is on and stays on until I reboot GHCi. None of this is the end of anybody's world, but I just think it would be easier for everyone -- particularly newcomers to Haskell -- if there were just a way to "force" loading, by enabling deferred type errors for one compilation. That's the proposal here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 22:42:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 22:42:18 -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.492234e939942fb98b320f9123bf9903@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: carlostome Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks, carlostome, for adopting this ticket. Let me know if I can be of any help -- `eir at cis.upenn.edu`, and on IRC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 22:48:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 22:48:36 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.059762e008aeab331a4328e1cc3a419e@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Template Haskell made no guarantees about the ordering of splice execution in 7.6.3, or of what definitions were available to `reify`. 7.8.3, on the other hand, says this (user manual, end of section 7.16.1): > The type environment seen by reify includes all the top-level declaration up to the end of the immediately preceding declaration group, but no more. > > A declaration group is the group of declarations created by a top-level declaration splice, plus those following it, down to but not including the next top-level declaration splice. The first declaration group in a module includes all top-level definitions down to but not including the first top-level declaration splice. So, I'd say that you were lucky that it worked in 7.6.3, but this is not erroneous behavior in 7.8.3. You can also fix the problem, by introducing a top-level splice, say {{{ $( return [] ) }}} After the declaration of `Huh`. Please close the ticket if you agree with my analysis. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 22:50:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 22:50:14 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.cbe689036e21e4c1bb9003a0b5d22397@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D452 | -------------------------------------+------------------------------------- Comment (by goldfire): I agree that this is a harder nut to crack than it initially appears. But, I'm surprised about the long build times. Were you using `make 2` in the `ghc` directory? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 22:59:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 22:59:36 -0000 Subject: [GHC] #8310: Can we change the semantics of `Trustworthy`? In-Reply-To: <045.91a9ef38d8b695a957254547374ae4ed@haskell.org> References: <045.91a9ef38d8b695a957254547374ae4ed@haskell.org> Message-ID: <060.3c56b0b8bf907fdaa6f38776f73061a5@haskell.org> #8310: Can we change the semantics of `Trustworthy`? -------------------------------------+------------------------------------- Reporter: ekmett | Owner: dterei Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dterei): * status: new => closed * resolution: => fixed Comment: Yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:01:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:01:54 -0000 Subject: [GHC] #8353: Easy way to defer type errors In-Reply-To: <047.34842edf8c636f9b11361128b151d960@haskell.org> References: <047.34842edf8c636f9b11361128b151d960@haskell.org> Message-ID: <062.98eae28d2cc9118a49fe920335c74468@haskell.org> #8353: Easy way to defer type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): You can say `:set -fno-defer-type-errors`. You don't need to reboot GHCi, do you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:03:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:03:02 -0000 Subject: [GHC] #9626: Test command lines munged on Windows when running on msys Python In-Reply-To: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> References: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> Message-ID: <060.7a9b846e9d5cc2541b526bd43b61cb87@haskell.org> #9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"101c62e26286353dd3fac1ef54323529b64c9902/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="101c62e26286353dd3fac1ef54323529b64c9902" The test runner now also works under the msys-native Python. Msys binaries apply heuristics to escape paths in arguments intended for non-msys binaries, which breaks timeout invocations, see #9626. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:03:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:03:02 -0000 Subject: [GHC] #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. In-Reply-To: <042.a15d898f52a182feca97f0f12eb7b2a0@haskell.org> References: <042.a15d898f52a182feca97f0f12eb7b2a0@haskell.org> Message-ID: <057.71c67fc96f30d8b5d0ef04af2c076558@haskell.org> #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. -------------------------------------+--------------------------------- Reporter: cjs | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: -------------------------------------+--------------------------------- Comment (by Austin Seipp ): In [changeset:"6fc78fdfa1482a31ed7b586f20c9d7cb592ea944/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6fc78fdfa1482a31ed7b586f20c9d7cb592ea944" Refactor: use System.FilePath.splitSearchPath Summary: To address #2521 ("Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg"), we were using a custom version of splitSearchPath (e4f46f5de). This solution however caused issue #9698 ("GHC_PACKAGE_PATH should be more lenient for empty paths"). This patch reverts back to System.FilePath.splitSearchPath (fixes #9698) and adresses (#2521) by testing for a trailing search path separators explicitly (instead of implicitly using empty search path elements). Empty paths are now allowed (ignored on Windows, interpreted as current directory on Posix systems), and trailing path separator still tack on the user and system package databases. Also update submodule filepath, which has a version of splitSearchPath which handles quotes in the same way as our custom version did. Test Plan: $ GHC_PACKAGE_PATH=/::/home: ./ghc-pkg list ... db stack: ["/",".","/home","",""] ... Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D414 GHC Trac Issues: #2521, #9698 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:03:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:03:02 -0000 Subject: [GHC] #9698: GHC_PACKAGE_PATH should be more lenient for empty paths In-Reply-To: <047.c636c8193d3a0be6c7f17bc6acc215b1@haskell.org> References: <047.c636c8193d3a0be6c7f17bc6acc215b1@haskell.org> Message-ID: <062.ac6a92cb69fb1b0c3cfed79510ea6dd3@haskell.org> #9698: GHC_PACKAGE_PATH should be more lenient for empty paths -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.3 Component: ghc-pkg | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #2521 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D414 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"6fc78fdfa1482a31ed7b586f20c9d7cb592ea944/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6fc78fdfa1482a31ed7b586f20c9d7cb592ea944" Refactor: use System.FilePath.splitSearchPath Summary: To address #2521 ("Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg"), we were using a custom version of splitSearchPath (e4f46f5de). This solution however caused issue #9698 ("GHC_PACKAGE_PATH should be more lenient for empty paths"). This patch reverts back to System.FilePath.splitSearchPath (fixes #9698) and adresses (#2521) by testing for a trailing search path separators explicitly (instead of implicitly using empty search path elements). Empty paths are now allowed (ignored on Windows, interpreted as current directory on Posix systems), and trailing path separator still tack on the user and system package databases. Also update submodule filepath, which has a version of splitSearchPath which handles quotes in the same way as our custom version did. Test Plan: $ GHC_PACKAGE_PATH=/::/home: ./ghc-pkg list ... db stack: ["/",".","/home","",""] ... Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D414 GHC Trac Issues: #2521, #9698 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:03:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:03:02 -0000 Subject: [GHC] #9807: Only test for bug #9439 when llvm is installed In-Reply-To: <049.ad5e3d70fc50bb323fb6edb8157fac2f@haskell.org> References: <049.ad5e3d70fc50bb323fb6edb8157fac2f@haskell.org> Message-ID: <064.3e25e5e845525a542c893503525b6227@haskell.org> #9807: Only test for bug #9439 when llvm is installed -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: Phab:D500 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"146dd138e2c3b4ec9b211dcbcedf752aeb79d3d1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="146dd138e2c3b4ec9b211dcbcedf752aeb79d3d1" Only test for bug #9439 when llvm is installed Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D500 GHC Trac Issues: #9807 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:03:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:03:02 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.510f181eda8385474fdbc4b8c6545cb7@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9268 | Differential Revisions: Phab:D150 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"146dd138e2c3b4ec9b211dcbcedf752aeb79d3d1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="146dd138e2c3b4ec9b211dcbcedf752aeb79d3d1" Only test for bug #9439 when llvm is installed Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D500 GHC Trac Issues: #9807 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:03:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:03:03 -0000 Subject: [GHC] #9736: Constant folding rules are wrong for GHCJS In-Reply-To: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> References: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> Message-ID: <059.17d45672e010ef76114873e2a674392e@haskell.org> #9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D502 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"4dd87c5e3ebd0569fdd19695f3e9c82102404a4f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4dd87c5e3ebd0569fdd19695f3e9c82102404a4f" use correct word size for shiftRightLogical and removeOp32 Summary: shiftRightLogical used a host sized Word for the intermediate value, which would produce the wrong result when cross compiling to a target with a different word size than the host. removeOp32 used the preprocessor to bake in word size assumptions, rather than getting the target word size from DynFlags Test Plan: validate Reviewers: hvr, rwbarton, carter, austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D502 GHC Trac Issues: #9736 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:03:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:03:03 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.65ce11ca82ba572af5ba68ec26db1b14@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: GregWeber Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8624 Test Case: | Blocking: | Differential Revisions: Phab:D460 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"33c029faef3b5e486def8f3a7c888dfa9f3d8cca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="33c029faef3b5e486def8f3a7c888dfa9f3d8cca" make TcRnMonad.lhs respect -ddump-to-file Summary: allows things such as: -ddump-to-file -ddump-splices Test Plan: compile with flags -ddump-to-file -ddump-splices verify that it does output an extra file Try out other flags. I noticed that with -ddump-tc there is some output going to file and some to stdout. Reviewers: hvr, austin Reviewed By: austin Subscribers: simonpj, thomie, carter Differential Revision: https://phabricator.haskell.org/D460 GHC Trac Issues: #9126 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:03:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:03:02 -0000 Subject: [GHC] #9396: Code cleanup: warning: use of GNU old-style field designator extension In-Reply-To: <042.7a09ae20cce6bfb1806d3d05f7f34b96@haskell.org> References: <042.7a09ae20cce6bfb1806d3d05f7f34b96@haskell.org> Message-ID: <057.82d5457a9d17b66e0a1b55a95238ed5b@haskell.org> #9396: Code cleanup: warning: use of GNU old-style field designator extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"8e0a480ca655010e67a38aca9b8705ecbd0f0c97/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8e0a480ca655010e67a38aca9b8705ecbd0f0c97" rts: remove old-style field designator extension (#9396) Authored-by: jrp Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:04:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:04:44 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.e904635d60e47bf2dd0ad983ef013299@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by owst): Hmm, I'm not particularly convinced. This extract: "The first declaration group in a module includes all top-level definitions down to but not including the first top-level declaration splice." seems to suggest that the declaration of Huh *is* included in the first declaration group, which is the immediately preceding declaration group to the splice. Am I misunderstanding something? The proposed "fix" seems somewhat spurious to me. Do you not agree that the original program seems reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:07:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:07:31 -0000 Subject: [GHC] #9396: Code cleanup: warning: use of GNU old-style field designator extension In-Reply-To: <042.7a09ae20cce6bfb1806d3d05f7f34b96@haskell.org> References: <042.7a09ae20cce6bfb1806d3d05f7f34b96@haskell.org> Message-ID: <057.93885ff9bfcd98ea7216272a48d4559a@haskell.org> #9396: Code cleanup: warning: use of GNU old-style field designator extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:07:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:07:47 -0000 Subject: [GHC] #8353: Easy way to defer type errors In-Reply-To: <047.34842edf8c636f9b11361128b151d960@haskell.org> References: <047.34842edf8c636f9b11361128b151d960@haskell.org> Message-ID: <062.e345df3082611c5bc36cb3fd3d00d1ca@haskell.org> #8353: Easy way to defer type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:3 simonpj]: > You can say `:set -fno-defer-type-errors`. You don't need to reboot GHCi, do you? Oops. Of course. I still think this would be a nice feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:07:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:07:59 -0000 Subject: [GHC] #9626: Test command lines munged on Windows when running on msys Python In-Reply-To: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> References: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> Message-ID: <060.e74b0f7697eceb416b2027576d6530ff@haskell.org> #9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks Gintas! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:09:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:09:42 -0000 Subject: [GHC] #9776: -frule-check flag not recognized without parameter In-Reply-To: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> References: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> Message-ID: <063.10e80265cc8c0d4b29069dd90a61db62@haskell.org> #9776: -frule-check flag not recognized without parameter -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: carlostome Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) warning at compile-time | Blocked By: Test Case: T9776 | Related Tickets: Blocking: | Differential Revisions: Phab:D503 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"80f6fc1769296330687d54179a6dc149f02d6348/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="80f6fc1769296330687d54179a6dc149f02d6348" compiler/main: fixes #9776 Test Plan: test T9776 under tests/driver Reviewers: jstolarek, austin Reviewed By: jstolarek, austin Subscribers: jstolarek, thomie, carter Differential Revision: https://phabricator.haskell.org/D503 GHC Trac Issues: #9776 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:11:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:11:02 -0000 Subject: [GHC] #9776: -frule-check flag not recognized without parameter In-Reply-To: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> References: <048.729dc51c9bc4fe9d529d0b3c6983c8de@haskell.org> Message-ID: <063.c9c17356252f7e4ee089ae0b7fe8cde0@haskell.org> #9776: -frule-check flag not recognized without parameter -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: carlostome Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Driver | Version: 7.9 Resolution: fixed | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Incorrect | than a day) warning at compile-time | Blocked By: Test Case: T9776 | Related Tickets: Blocking: | Differential Revisions: Phab:D503 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:13:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:13:09 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.ca5ea499001d1d8338742affb44ccfd4@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Only top-level declaration splices break up declaration groups. Your code has an expression splice, which is in the first declaration group and thus can't "see" it. I agree that your code ''is'' reasonable, but I also think that 7.8's behavior of breaking things into declaration groups is more predictable (once you know the rule). In general, otherwise, it would be quite hard for a human to figure out exactly which things are reifiable from a given splice -- it would all depend on GHC's internal topological sorting process. If you can propose an alternative, straightforward rule defining what should be available to `reify`, I'd be interested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:13:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:13:29 -0000 Subject: [GHC] #9807: Only test for bug #9439 when llvm is installed In-Reply-To: <049.ad5e3d70fc50bb323fb6edb8157fac2f@haskell.org> References: <049.ad5e3d70fc50bb323fb6edb8157fac2f@haskell.org> Message-ID: <064.ca4810ea289bf2f027d4d80c3f49c6b6@haskell.org> #9807: Only test for bug #9439 when llvm is installed -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: low | Version: 7.8.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: Phab:D500 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks thomie! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:14:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:14:54 -0000 Subject: [GHC] #9698: GHC_PACKAGE_PATH should be more lenient for empty paths In-Reply-To: <047.c636c8193d3a0be6c7f17bc6acc215b1@haskell.org> References: <047.c636c8193d3a0be6c7f17bc6acc215b1@haskell.org> Message-ID: <062.55b18627179e11f7894f47b734cd0cd6@haskell.org> #9698: GHC_PACKAGE_PATH should be more lenient for empty paths -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: ghc-pkg | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #2521 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D414 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:20:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:20:09 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.30b2c0ab07400dc969e8b986fbfd006c@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by owst): D'oh yes! I misread/misunderstood. Perhaps the manual could be tweaked to make the difference clear. Without understanding the implications, couldn't encountering an expression splice force the end of the current declaration group? In other words, act as if the splice was a declaration splice; since we can't have non-top-level type declarations, I think this might work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:26:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:26:50 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.070444d1e9273323bb44a3b4db1e55e9@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: infoneeded Type: task | Milestone: 7.10.1 Priority: lowest | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: Hey Iceland_Jack, these patches fell out of date again. I'm very sorry for doing this once more. :( Let me know and pester the hell out of me if you're willing to rebase this again please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:31:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:31:29 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.f561226ec123349ffc35796926827cdb@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: task | Milestone: 7.10.1 Priority: lowest | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:33:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:33:17 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.861c770a3ca8f5031415aaa72a7160a1@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): You are an ideal person to suggest a concrete wording change to the manual since you know what you misunderstood. Would you care to do that? No, a declaration splice can't force the end of a declaration group. What if it was mutually recursive with declarations further down? What if the mutually recursive group was scattered over the file? This way lies madness. That said, I am a bit surprised. The error message says that the renamer- lookup of `Huh` is failing, but I'd expect it to have brought all the names in the current group into scope. Moreover, types declarations are (reliably) typechecked before values decls. Worth looking into. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:36:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:36:51 -0000 Subject: [GHC] #8489: clean up dependency and usages handling in interface files In-Reply-To: <044.51af461702f35c8970f506002f551481@haskell.org> References: <044.51af461702f35c8970f506002f551481@haskell.org> Message-ID: <059.6dc33714ee3931a34947c02c1680f866@haskell.org> #8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): A good first step would be to write a precise specification for the change you propose. What will change? Is is just refactoring or will (TH) programmers see a difference? What will the difference be? I have no idea at the moment. Once the specification is clear, and agreed, the implementation can follow. But the latter should not precede the former. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 19 23:45:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Nov 2014 23:45:12 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.f38350fa262d7015ad01f305e588a9ef@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by owst): Yes, I agree I am, I will try to suggest some edits. And yes, I had a feeling mutually-recursive bindings would be the source of pain! Hmm. My next thought is why not just create declaration "groups" for each top-level declaration? What are we gaining by requiring groups with >1 member? If this happened, the definition of {{{Huh}}} would be its own declaration group, which would precede the reify, and all would be good... or would it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 00:41:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 00:41:42 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.39d3b8e5367a35ff74da8af9d06502f8@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: Phab:D504 | -------------------------------------+------------------------------------- Changes (by dredozubov): * differential: Phab:D497 => Phab:D504 Comment: Thanks for fast feedback! I've updated the code to build on your suggestions. Completely agree on "multiple -msse flags" point. It's completely reasonable to choose last version if multiple flags are provided by user. I feel like there's no need to leave VersionSuffix OptKind constructor(and code related to it), because there will be no application for it - it was commited and used only to support msse flags. I'd gladly supply some tests if i haven't been extremely frustrated how to do this. Any pointers on this matter will be greatly appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 00:42:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 00:42:13 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.45df989a360d797612fe05e5446fbdfa@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 Comment: I'm actually backing this out of 7.8 right now due to some worries about #9722; it also introduces API additions in 7.8.4 we should be careful about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 01:02:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 01:02:43 -0000 Subject: [GHC] #8285: unexpected behavior with encodeFloat on large inputs In-Reply-To: <045.f7eaecd94e96f3fd291d7a1c2d15ebef@haskell.org> References: <045.f7eaecd94e96f3fd291d7a1c2d15ebef@haskell.org> Message-ID: <060.360b37d8547dd3fe9abea312e5f1125a@haskell.org> #8285: unexpected behavior with encodeFloat on large inputs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:2 hvr]: > PS: Now I see the problem What is exactly the problem? That the second argument to `encodeFloat` is treated as a 32 bit integer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 01:06:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 01:06:36 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.a71e895d7c311a6d9658f907c3e94067@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 01:38:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 01:38:58 -0000 Subject: [GHC] #8265: getTokenStream fails for source using cpp In-Reply-To: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> References: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> Message-ID: <059.752ae23803edd9c272ea6305aa0b8753@haskell.org> #8265: getTokenStream fails for source using cpp -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Linux => Unknown/Multiple Comment: To reproduce, use `BCpp.hs` and `tokenbug.2.hs` from above. {{{ $ cabal install ghc-paths $ ghc -package ghc tokenbug.2.hs $ ./tokenbug.2 got saf:("./BCpp.hs",) got src:[{-# LANGUAGE CPP #-} -- Check that we can parse a file which requires CPP module BCpp where bob :: Int -> Int -> Int #if __GLASGOW_HASKELL__ > 704 bob x y = x + y #else bob x y = x + y * 2 #endif ] got saf:("./BCpp.hs",) tokenbug.2: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): parse failed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 01:39:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 01:39:36 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.730ee325129fa8d2c1e248747acbb8c4@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by janm): I am running a test build now but code inspection shows that the same race is present. I expect it to fail. We resolved the issue by single-threading all package installation in the build process. We are running on 9.3-p5 at the moment -- It was probably 9.2-RELEASE or 9-STABLE at the time of the original bug report. I also see that the FreeBSD port for lang/ghc limits concurrency to 4 jobs, added in SVN rev 348842. Assuming you're also pgj at freebsd you committed the change, so probably know! This was in response to FreeBSD bug ports/186829 (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186829 ). The same problem seems to be the underlying cause. The error trace in the bug report shows cabal failing to install a package, just like I saw in my system build processes. Resolving the problem in ghc-pkg should resolve this problem and allow lang/ghc builds to run with full parallelism. In principle, the withFileAtomic function should (in order): 1. take a lock on the target file (creating it if it is not present) 2. create the temporary file 3. write to the temporary file 4. close the temporary file 5. rename the temporary file on top of the locked target file 6. close the original target file which is now no longer present in the file system. Concurrent execution will now be serialised around the lock on the target file. This doesn't resolve the "big hairy race condition" on Windows, but it should resolve the big hairy race condition I'm hitting that isn't mentioned code comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 01:49:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 01:49:38 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.1601847c12b978021ffb85bb031caaea@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d87fa343cd5d298c9fea96d65d05a20929ff97d0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d87fa343cd5d298c9fea96d65d05a20929ff97d0" arm64: 64bit iOS and SMP support (#7942) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 01:49:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 01:49:38 -0000 Subject: [GHC] #9703: Add missing calling conventions to Template Haskell In-Reply-To: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> References: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> Message-ID: <059.4042a3b7a1b8d9774605e63397ad9295@haskell.org> #9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: cmsaperstein Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D353 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"c6e12e69fa348328d58540a1ea8abed35d0dda32/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c6e12e69fa348328d58540a1ea8abed35d0dda32" Make calling conventions in template haskell Syntax.hs consistent with those in ghc ForeignCall.hs this impliments #9703 from ghc trac Test Plan: still needs tests Reviewers: cmsaperstein, ekmett, goldfire, austin Reviewed By: goldfire, austin Subscribers: goldfire, thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D353 GHC Trac Issues: #9703 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 01:50:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 01:50:05 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.4d46d09e957584aea58727a991cdcea3@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks Luke! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 01:57:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 01:57:46 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.b9d50812422454c31ec54fb18ebd178e@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Not reading this thread closely, but since there's also a comment that says "copied from Cabal's Distribution.Simple.Utils", there might be a function in there now that does exactly what you need: https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Utils.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 02:11:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 02:11:30 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.af47ce271b32e6564de92c284dd34d3a@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gcampax): * cc: gcampax (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 02:46:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 02:46:19 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.22d27b6ea78380696de1c30d9d201bda@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by janm): Thanks for the reply. A quick code inspection of the renameFile function shows the same race. The function is atomic for single threaded execution (ie. all or nothing for the updated file), but updates can be lost when there is concurrent execution of two processes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 03:10:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 03:10:55 -0000 Subject: [GHC] #9814: Add Data.Void to base Message-ID: <046.50c1f1ca69dc11e2d1b5288936528b83@haskell.org> #9814: Add Data.Void to base -------------------------------------+------------------------------------- Reporter: shachaf | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Last year I [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/19867 proposed] adding `Data.Void`, with a canonical uninhabited type `Void`, to base. This would replace the module of the same name in Edwardk Kmett's [http://hackage.haskell.org/package/void void] package (and in turn he'll update his package to re?xport the module from base). The response to the proposal was mostly positive; there were a couple of objections to the name, but `Void` is so standard by now that it seems pointless to change it, and no better name was suggested. Unfortunately I never did anything about it at the end of the discussion period. Recently several people have asked me to move this proposal along, and I'm finally getting around to making the ticket. Hopefully it can happen before the 7.10 freeze. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 03:28:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 03:28:43 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.313d188d45466500f1a238918947e2e9@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) Comment: Previous discussion: http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/1690 https://www.haskell.org/pipermail/haskell-cafe/2010-December/087078.html I'm not sure what to do. You mention "when a new user is created there is also simultaneously a group created with the same name". Isn't it possible for other users to also be a member of that group (and even that the user owner isn't: user andrew doesn't need to be a member of group andrew)? Note: file permissions of `~/.pythonrc.py` are not checked at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 03:36:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 03:36:32 -0000 Subject: [GHC] #9703: Add missing calling conventions to Template Haskell In-Reply-To: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> References: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> Message-ID: <059.5d13503db146c30fdebb8a5217fba142@haskell.org> #9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: cmsaperstein Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D353 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Craig Saperstein and Luite Stegeman are shared authors for this patch. Even though the commit message says "still needs tests", they have actually been added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 03:36:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 03:36:47 -0000 Subject: [GHC] #9703: Add missing calling conventions to Template Haskell In-Reply-To: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> References: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> Message-ID: <059.c3cd93f7ca0deb877f58eb6a090882a6@haskell.org> #9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: cmsaperstein Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D353 | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 03:39:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 03:39:17 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.2fafe247945ba7e8a6cffd3b9f430b53@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: #9324 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: mboes (added) * related: => #9324 Comment: cc mboes, since he was the last one to touch this code, and maybe has an opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 04:17:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 04:17:36 -0000 Subject: [GHC] #9815: Runtime error with RecordWildCards and a non-record constructor Message-ID: <043.28b061d1b50c39a8e997a8d356845e54@haskell.org> #9815: Runtime error with RecordWildCards and a non-record constructor -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: RecordWildCards, | Operating System: warning | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | accepts invalid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following program is accepted with no warning, and crashes at runtime with an error: {{{#!hs {-# LANGUAGE RecordWildCards #-} newtype N = N Int deriving (Show) main = print N{..} }}} {{{ % runghc wildcards.hs wildcards.hs: wildcards.hs:4:14-18: Missing field in record construction }}} I find this behavior surprising. Would it be better to either disallow it or have `-fwarn-missing-fields` warn it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 04:20:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 04:20:53 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.91ac917151b6551fefa23a1885d63df7@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun004 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Harbormaster just [https://phabricator.haskell.org/harbormaster/build/2075/ failed] on `ghcirun004` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 04:32:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 04:32:39 -0000 Subject: [GHC] #9815: Runtime error with RecordWildCards and a non-record constructor In-Reply-To: <043.28b061d1b50c39a8e997a8d356845e54@haskell.org> References: <043.28b061d1b50c39a8e997a8d356845e54@haskell.org> Message-ID: <058.00b21ef23e148f5a7ffee7617f488710@haskell.org> #9815: Runtime error with RecordWildCards and a non-record constructor -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: RecordWildCards, Resolution: | warning Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by liyang): * cc: ghc.haskell.org@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 04:37:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 04:37:45 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.b16ef8ad367fee699c3b027d12167940@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): :( ok -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 05:37:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 05:37:54 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.1f42f7f9d73cc1eac29e8dce5a47485c@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:5 janm]: > I am running a test build now but code inspection shows that the same race is present. I expect it to fail. All right, excellent, thanks. > I also see that the FreeBSD port for lang/ghc limits concurrency to 4 jobs, added in SVN rev 348842. Assuming you're also pgj at freebsd you committed the change, so probably know! This was in response to FreeBSD bug ports/186829. Well, to be honest, I did not realize that it was a related issue. In the past, the GHC build system already had problems with parallel builds on FreeBSD due to e.g. low-resolution timestamps in the file system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 06:25:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 06:25:08 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.feb826a171d70cb57826b10fe9529a75@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:6 thomie]: > Not reading this thread closely, but since there's also a comment that says "copied from Cabal's Distribution.Simple.Utils", there might be a function in there now that does exactly what you need: > https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Utils.hs Yeah, I know that -- this is the issue that also causes me headaches on my Windows builders recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 06:55:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 06:55:35 -0000 Subject: [GHC] #9814: Add Data.Void to base In-Reply-To: <046.50c1f1ca69dc11e2d1b5288936528b83@haskell.org> References: <046.50c1f1ca69dc11e2d1b5288936528b83@haskell.org> Message-ID: <061.828f9b77b31c48a1d1752c89ce590b88@haskell.org> #9814: Add Data.Void to base -------------------------------------+------------------------------------- Reporter: shachaf | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: ekmett => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 07:09:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 07:09:28 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files In-Reply-To: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> References: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> Message-ID: <058.a49d3f7f01683f72662164b19faa68d4@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files -------------------------------------+------------------------------------- Reporter: janm | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: ghc-pkg race Resolution: | Architecture: Unknown/Multiple Operating System: FreeBSD | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by janm): Replying to [comment:8 pgj]: > Replying to [comment:5 janm]: > > I am running a test build now but code inspection shows that the same race is present. I expect it to fail. > > All right, excellent, thanks. Interestingly enough it didn't fail. I suspect that it is because we have switch to pkg from the old-style packaging system on FreeBSD. We have local modifications to retry database access due to contention during package installation. This may be serialising execution of the Haskell installation processes. I will remove the JOBS limit in lang/ghc and rerun -- that should fail because there is no pkg database. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 07:17:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 07:17:41 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.13e13165e94c5875c26c61d759f989da@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: Phab:D504 | -------------------------------------+------------------------------------- Comment (by jstolarek): > I agree on "multiple -msse flags" point. It's completely reasonable to choose last version if multiple flags were provided by user. What do you mean by "last version". "Latest SSE version" or "last version given on the command line"? I meant the former. As for tests, you can test that: 1. all `msse` flags are listed by `--show-options` flag 2. incorrect `-msse` flag is rejected (see https://phabricator.haskell.org/D503 for an example how to do that). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 07:35:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 07:35:49 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.0ec12a7af43d72e7d5adc73e925e793e@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: #9324 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): IMHO, `.ghci` is comparable to `.bash_profile`/`.bashrc` et al, in that it allows code to be injected if not properly protected against users. Otoh, maybe we could define a magic comment to be placed at the start of `.ghci` to disregard this protection. E.g. something simple as {{{ -- insecure :set ... :def ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 07:39:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 07:39:12 -0000 Subject: [GHC] #9789: Make GHC accept .format+lhs as extension for literate haskell files In-Reply-To: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> References: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> Message-ID: <060.c35b513f1844b48e899f47ad105136fa@haskell.org> #9789: Make GHC accept .format+lhs as extension for literate haskell files -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by merijn): More discussion https://www.haskell.org/pipermail/ghc- devs/2014-November/007319.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 07:40:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 07:40:20 -0000 Subject: [GHC] #9789: Make GHC accept .format+lhs as extension for literate haskell files In-Reply-To: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> References: <045.0ee2d07631edaab55e4c5041d57fbc27@haskell.org> Message-ID: <060.ed5624343fa71a639114aa2548fe2f0e@haskell.org> #9789: Make GHC accept .format+lhs as extension for literate haskell files -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by merijn): Proposal wiki page: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 07:42:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 07:42:16 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.dac46c57ed89df235238686748dfff82@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: Phab:D504 | -------------------------------------+------------------------------------- Comment (by carter): additionally, im not sure if higher SSE numbers imply support for prior extensions, at least on non intel CPUS (in some cases it certainly does, but That maybe should be checked?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 09:44:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 09:44:08 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.9d27f7e91a066a602572fe124f2afe64@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"8cbd25a49051171da7c73db57ebd87bb0296c2f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8cbd25a49051171da7c73db57ebd87bb0296c2f7" Make Data.Functor.Identity trustworthy again Alas `{-# LANGUAGE Safe #-}` can't be used since `Data.Coerce` isn't "safe". However, we use `coerce` just as an optimisation (see also 4ba884bdd3a9521ea92fcda8f601a7d0f3537bc1 which broke the safe-inferred status of `Data.Functor.Identity`), so this module at least deserves `{-# LANGUAGE Trustworthy #-}`. NOTE: `Data.Functor.Identity` was added to `base` in the context of #9664 Reviewed By: luite Differential Revision: https://phabricator.haskell.org/D507 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 10:35:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 10:35:07 -0000 Subject: [GHC] #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` In-Reply-To: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> References: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> Message-ID: <063.5183bc16f71e60722d072ed3be6ae153@haskell.org> #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D508 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D508 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 13:23:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 13:23:02 -0000 Subject: [GHC] #8489: clean up dependency and usages handling in interface files In-Reply-To: <044.51af461702f35c8970f506002f551481@haskell.org> References: <044.51af461702f35c8970f506002f551481@haskell.org> Message-ID: <059.363d73bead01dec9aa736386bb80e536@haskell.org> #8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by errge): Simon, yes of course, it is important to first agree on what we want. On the other hand, this is a much smaller change than my changes from previous year, so I do not think that we need a whole wiki page again. Let me put it here what I think the issue is and then you can point it out where I was not precise enough and we can complete this to a "specification". Take the following program: {{{#!haskell {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH import Language.Haskell.TH.Syntax $(do let mod = Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary") ModuleInfo info <- reifyModule mod runIO $ mapM_ print info return []) main = return () }}} On my machine, the output is: {{{ Module (PkgName "base") (ModName "Data.Either") Module (PkgName "base") (ModName "Data.Maybe") Module (PkgName "base") (ModName "Data.Word") Module (PkgName "base") (ModName "GHC.Base") Module (PkgName "base") (ModName "GHC.IO") Module (PkgName "base") (ModName "GHC.IO.IOMode") Module (PkgName "base") (ModName "GHC.Word") Module (PkgName "base") (ModName "Prelude") Module (PkgName "base") (ModName "System.IO") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Class") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Generic") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Get") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Get.Internal") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Put") Module (PkgName "bytestring-0.10.4.0") (ModName "Data.ByteString") Module (PkgName "bytestring-0.10.4.0") (ModName "Data.ByteString.Lazy") Module (PkgName "bytestring-0.10.4.0") (ModName "Data.ByteString.Lazy.Internal") Module (PkgName "ghc-prim") (ModName "GHC.Types") }}} And looking at http://hackage.haskell.org/package/binary-0.7.1.0/docs/src /Data-Binary.html it can be seen that we do not import GHC.Types in binary. So from the programmer point of view, this change should make the ModuleInfo list returned by module reification only contain the actual direct imports. So this is my goal, before discussing implementation details inside GHC, may I ask if this description is clear enough and if others agree with the goal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 13:34:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 13:34:23 -0000 Subject: [GHC] #9814: Add Data.Void to base In-Reply-To: <046.50c1f1ca69dc11e2d1b5288936528b83@haskell.org> References: <046.50c1f1ca69dc11e2d1b5288936528b83@haskell.org> Message-ID: <061.85721978a838f34a17c2020b189a7457@haskell.org> #9814: Add Data.Void to base -------------------------------------+------------------------------------- Reporter: shachaf | Owner: hvr Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D506 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D506 * version: 7.8.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 13:59:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 13:59:39 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.d3ca4e57000c95656e66008cd9334f01@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D452 | -------------------------------------+------------------------------------- Comment (by rodlogic): I didn't know that {{{make 2}}} existed, thanks for the tip. There is one thing that bothers me, though. It seems that it is going to be quite hard to get the parser behaving the same with/without the haddock flag (granted it may not be such an important problem). We'll need to change happy rules everywhere to make it accept the same source files. Wouldn't it make more sense to have comments in general (as opposed to haddock specific documentation attached to specific declarations) as first class AST nodes that can be included/excluded based on a general parse- comments flag? This way a parser plugin could be added to the pipeline, consume the AST with comments, and parse the comments however it wants based on whether it is before or after a declaration. And haddock could be completely independent from the GHC parser. I understand that this may be a big change that is not worth pursuing at this point in time, but I am curious about what your opinion is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 14:41:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 14:41:47 -0000 Subject: [GHC] #8584: Pattern synonym type signatures In-Reply-To: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> References: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> Message-ID: <060.6fb39fd891bcf817edf48b5101e0b800@haskell.org> #8584: Pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: pattern synonyms (Type checker) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: 5144 Unknown/Multiple | Related Tickets: 8581 Type of failure: | None/Unknown | Test Case: | Blocking: 8968 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 14:42:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 14:42:12 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.65bfd167b678d58e16ebbf87aeb2b979@haskell.org> #8968: Pattern synonyms and GADTs -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 (Type checker) | Keywords: pattern synonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8584 Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => closed * resolution: => fixed Comment: Fixed as part of #8584. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 14:52:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 14:52:10 -0000 Subject: [GHC] #8489: clean up dependency and usages handling in interface files In-Reply-To: <044.51af461702f35c8970f506002f551481@haskell.org> References: <044.51af461702f35c8970f506002f551481@haskell.org> Message-ID: <059.a8ca1ed9ab5208fb0abe471841e53a63@haskell.org> #8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Aha I see. So this is really a bug, thus: * Template Haskell offers {{{ reifyModule :: Module -> Q ModuleInfo data ModuleInfo = ModuleInfo [Module] -- Contains the import list of the module }}} * The "import list of the module" M presumably means the list of modules that M imports directly. (Clarifying the comment would be good.) * But the program above shows that `reifyModule` reports a much longer list. (NB: A smaller test case would make easier.) So the specification is simply to make `reifyModudule` behave as advertised. Now I understand, it's easy enough to implement, at least for modules in the same package as M. Just pick modules whose `Usage` has `Just _` in its `usg_exports` field. Sadly, for modules from other pacakges we simply don't record the necessary information in interface files at all. It would not be hard to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 15:19:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 15:19:40 -0000 Subject: [GHC] #8489: clean up dependency and usages handling in interface files In-Reply-To: <044.51af461702f35c8970f506002f551481@haskell.org> References: <044.51af461702f35c8970f506002f551481@haskell.org> Message-ID: <059.7c025ca66167e34ead1e5147b9c4d6b9@haskell.org> #8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by errge): If I remember correctly the difference is not the package boundary, but the compilation unit boundary. So if you compile your modules with different GHC invocations by using -c instead of --make, then you will not have the `usg_exports` either, am I right? If that is the case I prefer us to do the right fix and include this information in the interfaces files and do not introduce different behavior depending on compilation technique in the meantime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 15:23:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 15:23:39 -0000 Subject: [GHC] #8489: clean up dependency and usages handling in interface files In-Reply-To: <044.51af461702f35c8970f506002f551481@haskell.org> References: <044.51af461702f35c8970f506002f551481@haskell.org> Message-ID: <059.73c710d17454d0d628b3bca65c9d73f7@haskell.org> #8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I believe its the package boundary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 16:45:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 16:45:28 -0000 Subject: [GHC] #8213: Bad error message when using lazy IO to read from closed handle In-Reply-To: <042.5924f470797110e67b267f26b67ddb5f@haskell.org> References: <042.5924f470797110e67b267f26b67ddb5f@haskell.org> Message-ID: <057.ee34fa27c40c0a04a1fa914d703a747c@haskell.org> #8213: Bad error message when using lazy IO to read from closed handle -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core | Version: 7.6.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * failure: Documentation bug => Incorrect result at runtime * status: new => infoneeded * component: Runtime System => Core Libraries Old description: > Today I accidentally wrote this code: > > {{{ > filesEqual :: FilePath -> FilePath -> IO Bool > filesEqual f1 f2 = do > equal <- withBinaryFile f1 ReadMode $ \f1 -> > withBinaryFile f2 ReadMode $ \f2 -> > c1 <- BSL.hGetContents h1 > c2 <- BSL.hGetContents h2 > return (c1 == c2) > return $! equal > }}} > > The problem is that I should have done the forcing before the files are > closed: > > {{{ > return $! (c1 == c2) > }}} > > I got the incredibly unhelpful error message > > {{{ > myprogram: myfile.txt: illegal operation > }}} > > It took me 2 hours and strace to find out what was going on, especially > because around every file open() there are multiple things that map top > IllegalOperation (e.g. the ENOTTY from the ioctl that checks whether the > device is a TTY). > > Can we give a better error message here, at least mentioning that the > problem has to do with closed (and GC'd) handles? New description: Today I accidentally wrote this code: {{{ import System.IO import Data.ByteString.Lazy as BSL filesEqual :: FilePath -> FilePath -> IO Bool filesEqual f1 f2 = do equal <- withBinaryFile f1 ReadMode $ \h1 -> withBinaryFile f2 ReadMode $ \h2 -> do c1 <- BSL.hGetContents h1 c2 <- BSL.hGetContents h2 return (c1 == c2) return $! equal main = filesEqual "test.hs" "test.hs" >>= print }}} The problem is that I should have done the forcing before the files are closed: {{{ return $! (c1 == c2) }}} I got the incredibly unhelpful error message {{{ test: test.hs: illegal operation }}} It took me 2 hours and strace to find out what was going on, especially because around every file open() there are multiple things that map top IllegalOperation (e.g. the ENOTTY from the ioctl that checks whether the device is a TTY). Can we give a better error message here, at least mentioning that the problem has to do with closed (and GC'd) handles? -- Comment: I can not reproduce the problem. nh2: which OS were you using? Can you try again? On Linux, I get the following (nice) error message: {{{ $ ghc-7.6.3 test.hs ... $ ./test test: test.hs: hGetBufSome: illegal operation (handle is closed) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 17:55:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 17:55:56 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.629fd3b166cd61080d448f8f00391f94@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D510 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D510 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 18:03:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 18:03:18 -0000 Subject: [GHC] #2437: More accurate package dependencies In-Reply-To: <047.68fd28011c214b441523af716564e799@haskell.org> References: <047.68fd28011c214b441523af716564e799@haskell.org> Message-ID: <062.6446858842f48491be02df86c3f3ad4b@haskell.org> #2437: More accurate package dependencies -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Package | Version: 6.8.3 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: #3560, #8174 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #3560, #8174 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 18:04:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 18:04:23 -0000 Subject: [GHC] #8174: GHC should not load packages for TH if they are not used In-Reply-To: <042.1ed57189b3c7e645a380321c747a4ab5@haskell.org> References: <042.1ed57189b3c7e645a380321c747a4ab5@haskell.org> Message-ID: <057.e7834f7ef48489a19a09d95f537dd9e5@haskell.org> #8174: GHC should not load packages for TH if they are not used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #2437 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #2437 Comment: This seems to be covered by #2437. I added a link back to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 18:29:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 18:29:37 -0000 Subject: [GHC] #8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone" In-Reply-To: <045.ae6d7c8dc2cac763fcfd91e8b07b080d@haskell.org> References: <045.ae6d7c8dc2cac763fcfd91e8b07b080d@haskell.org> Message-ID: <060.f435e4c9dbef2022fc8e6adecb9ad5b7@haskell.org> #8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone" -------------------------------------+------------------------------------- Reporter: sp55aa | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Simplifier, Operating System: | UnfoldingDone, simpl-tick-factor Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Windows => Unknown/Multiple * architecture: x86 => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 18:30:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 18:30:52 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.12ada0b4cfdfdb1aae209a3322a74c79@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: feature | Milestone: request | Version: 7.6.3 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple (Type checker) | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 18:49:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 18:49:01 -0000 Subject: [GHC] #8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails In-Reply-To: <045.760cae9f013a16aed8eac702a0c53725@haskell.org> References: <045.760cae9f013a16aed8eac702a0c53725@haskell.org> Message-ID: <060.d8b4dc013e10dd3573ae6c25eeae38e5@haskell.org> #8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails -------------------------------------+------------------------------------- Reporter: troydm | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Can you try again with GHC 7.8.3? Does this problem only occur on Solaris? I can not reproduce it on Linux. Note: to compile with 7.4.2, first `cabal install transformers`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 18:58:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 18:58:32 -0000 Subject: [GHC] #8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported In-Reply-To: <046.2c433f8cbc6c486af267486ff9ed1e9c@haskell.org> References: <046.2c433f8cbc6c486af267486ff9ed1e9c@haskell.org> Message-ID: <061.ccc3e94369c0b8056101e7460ae328f3@haskell.org> #8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This was fixed in or before 7.8.3. A regression test should probably be added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 19:06:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 19:06:15 -0000 Subject: [GHC] #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` In-Reply-To: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> References: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> Message-ID: <063.8649037ed98ba59c55671269c6fb02c4@haskell.org> #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D508 | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"696fc4ba5b36f478d8daec56656ebf7d99e18159/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="696fc4ba5b36f478d8daec56656ebf7d99e18159" Split SynTyCon to SynonymTyCon and FamilyTyCon This patch refactors internal representation of type synonyms and type families by splitting them into two separate data constructors of TyCon data type. The main motivation is is that some fields make sense only for type synonyms and some make sense only for type families. This will be even more true with the upcoming injective type families. There is also some refactoring of names to keep the naming constistent. And thus tc_kind field has become tyConKind and tc_roles has become tcRoles. Both changes are not visible from the outside of TyCon module. Updates haddock submodule Reviewers: simonpj Differential Revision: https://phabricator.haskell.org/D508 GHC Trac Issues: #9812 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 19:08:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 19:08:13 -0000 Subject: [GHC] #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` In-Reply-To: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> References: <048.4866ee60f605f71fd09e288292fbe44d@haskell.org> Message-ID: <063.6e1c83ece7fb93ba11a4317eb56ab689@haskell.org> #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D508 | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:12:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:12:56 -0000 Subject: [GHC] #9816: Add function for size-checked conversion of Integral types Message-ID: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> #9816: Add function for size-checked conversion of Integral types -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Based on the discussion in [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23338 this thread], I would like to add a function to the {{{base}}} library that is similar to {{{fromIntegral}}} but only successful if the argument fits in the result type. If possible, I would like to get this into 7.10. My apologies for running late on it. Hopefully, since it is a relatively small change overall, the "only" controversy will be bikeshedding. I have concluded that adding @hvr's {{{intCastMaybe}}} from [http://hackage.haskell.org/package/int-cast int-cast] is the best possible option. Previously, I thought a {{{Bounded}}}-based version was also useful; however, I realized that it did not deal properly with conversions like {{{Int<->Word}}}/{{{Int8<->Word8}}}/etc. as well as {{{intCastMaybe}}} and would need specialized versions that {{{intCastMaybe}}} provides automatically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:16:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:16:44 -0000 Subject: [GHC] #9816: Add function for size-checked conversion of Integral types In-Reply-To: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> References: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> Message-ID: <057.65ac5f2fc2c9ab483faba0326f9f879e@haskell.org> #9816: Add function for size-checked conversion of Integral types -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spl): Phab diff coming momentarily, I hope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:27:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:27:37 -0000 Subject: [GHC] #9816: Add function for size-checked conversion of Integral types In-Reply-To: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> References: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> Message-ID: <057.8211b0d1daf7682bd60d985b6f6577a8@haskell.org> #9816: Add function for size-checked conversion of Integral types -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.9 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: D512 | -------------------------------------+------------------------------------- Changes (by spl): * status: new => patch * differential: => D512 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:12 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.be3a9bf0e933b95b3060ce16836e37b3@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D429 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5a8ae60ef9dc52ab04350ffbcf2945c9177eac87/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5a8ae60ef9dc52ab04350ffbcf2945c9177eac87" Fix #9209, by reporting an error instead of panicking on bad splices. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:12 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.da9a82f8573bd6b9cfe7c1cbdf68f629@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D429 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6db0f6fe40287f16d34d12efae9249d2feb4878a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6db0f6fe40287f16d34d12efae9249d2feb4878a" Test #9209 in th/T9209 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:12 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.d7d8b89fd8c1ca26d73843b0f7595a67@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e394e74df5ca8081c0ffd147d34e788d290fb21a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e394e74df5ca8081c0ffd147d34e788d290fb21a" Fix #9220 by adding role annotations. This includes a submodule update for `array`. There is also an added test in libraries/array/tests/T9220. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:12 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.b6c39207eae24dd1d952dc0f88a458c8@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #9427 rejects valid program | Test Case: | polykinds/T9200 polykinds/T9200b | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"67abfdacf5c93cccb0ab780b524591c916b21c3f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="67abfdacf5c93cccb0ab780b524591c916b21c3f" Test #9151 in typecheck/should_compile/T9151. This test case should pass right now -- the bug is fixed, presumably by #9200. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:12 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.0e46e0707a733f95f1a07d0c53f00f6d@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"67abfdacf5c93cccb0ab780b524591c916b21c3f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="67abfdacf5c93cccb0ab780b524591c916b21c3f" Test #9151 in typecheck/should_compile/T9151. This test case should pass right now -- the bug is fixed, presumably by #9200. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:13 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.160a08161011b8b1a7b6af9fb86ab294@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: goldfire Type: feature | Status: closed request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: th/T8100 | Blocking: | Differential Revisions: Phab:D439 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"786b62aa57e4dcc528e2da2f7d0451ab834d655a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="786b62aa57e4dcc528e2da2f7d0451ab834d655a" Add release notes for #8100, #9527, and #9064. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:13 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions In-Reply-To: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> References: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> Message-ID: <062.b104e4647e86af25fe58efa65efe696c@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5eebd990ea7a5bc1937657b101ae83475e20fc7a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5eebd990ea7a5bc1937657b101ae83475e20fc7a" Test #9318 in typecheck/should_fail/T9318 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:13 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.0b0b611f4425f088da89e96764a0d019@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D437 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"786b62aa57e4dcc528e2da2f7d0451ab834d655a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="786b62aa57e4dcc528e2da2f7d0451ab834d655a" Add release notes for #8100, #9527, and #9064. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:12 -0000 Subject: [GHC] #9064: Support default class method signatures in Template Haskell In-Reply-To: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> References: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> Message-ID: <062.bfdfc9b514d72b1e2b580ff5b6846b0b@haskell.org> #9064: Support default class method signatures in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: th/T9064 | Blocking: | Differential Revisions: Phab:D440 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"786b62aa57e4dcc528e2da2f7d0451ab834d655a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="786b62aa57e4dcc528e2da2f7d0451ab834d655a" Add release notes for #8100, #9527, and #9064. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:13 -0000 Subject: [GHC] #9201: GHC unexpectedly refines explicit kind signatures In-Reply-To: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> References: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> Message-ID: <060.7c584fad9e12a800420a04917ec3ea27@haskell.org> #9201: GHC unexpectedly refines explicit kind signatures -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"8fea2acde696f9960ffcf84f512235bbf4b481d6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8fea2acde696f9960ffcf84f512235bbf4b481d6" Test #9201 in typecheck/should_fail/T9201 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:13 -0000 Subject: [GHC] #9788: `coerce` has an impossible type In-Reply-To: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> References: <047.7c6f9c72989805a9b4570c15fe75b64b@haskell.org> Message-ID: <062.562b6cb4cb9ca430a40139a9b50d7d1b@haskell.org> #9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D468 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"113a37b6e39a3b4964ea6d93fd7adf30adb39426/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="113a37b6e39a3b4964ea6d93fd7adf30adb39426" Update manual to get rid of bogus `coerce` example (#9788) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:41:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:41:13 -0000 Subject: [GHC] #9109: Improve error messages around "untouchable" type variables In-Reply-To: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> References: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> Message-ID: <062.2c1efa56e1bc9265d04e06233124b4b8@haskell.org> #9109: Improve error messages around "untouchable" type variables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"cb41e08e4ce687356d1345ad6a1aa3555e505a59/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cb41e08e4ce687356d1345ad6a1aa3555e505a59" Test #9109 in typecheck/should_fail/T9109 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:44:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:44:48 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.ebb82d1e42da847c700d97b539b3041d@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: th/T9209 | Blocking: | Differential Revisions: Phab:D429 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * testcase: => th/T9209 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:45:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:45:20 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.cb47e6eaaac74b608c76c1c62fe6efa3@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | libraries/array/tests/T9220 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => libraries/array/tests/T9220 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:45:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:45:53 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.85c64859abfef06034560b69e7599d3c@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | typecheck/should_compile/T9151 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_compile/T9151 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:46:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:46:12 -0000 Subject: [GHC] #9201: GHC unexpectedly refines explicit kind signatures In-Reply-To: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> References: <045.58b3385e1edd9977dfe0a46c17d9ab9b@haskell.org> Message-ID: <060.3b578dc1295f0e20fa30399ad90ef296@haskell.org> #9201: GHC unexpectedly refines explicit kind signatures -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | typecheck/should_fail/T9201 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_fail/T9201 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:46:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:46:21 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions In-Reply-To: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> References: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> Message-ID: <062.1a20a9a2f68535491489ca0f938fc78c@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T9318 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_fail/T9318 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 21:46:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 21:46:32 -0000 Subject: [GHC] #9109: Improve error messages around "untouchable" type variables In-Reply-To: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> References: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> Message-ID: <062.c139e9d708f665559dc55c8314dc5855@haskell.org> #9109: Improve error messages around "untouchable" type variables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | typecheck/should_fail/T9109 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_fail/T9109 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 22:00:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 22:00:32 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.d2ce3f7bb9c3dfe694d3eaae39942d82@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: GregWeber Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8624 Test Case: | Blocking: | Differential Revisions: Phab:D460 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 22:08:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 22:08:31 -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.eea0e236ea70eb9ecf501ceb3fe4ee6e@haskell.org> #8406: Invalid object in isRetainer() or Segfault -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: worksforme | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Let's close it then, things have changed quite a bit since 7.6.3. If the problems shows up again, please do re-open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 23:21:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 23:21:09 -0000 Subject: [GHC] #3511: port GHC to OpenBSD/sparc64 (unregisterised is fine) In-Reply-To: <044.84975b11fc9b3b424090411fd29c2c83@haskell.org> References: <044.84975b11fc9b3b424090411fd29c2c83@haskell.org> Message-ID: <059.7489231d86f2a0fedba5dd545ff43f69@haskell.org> #3511: port GHC to OpenBSD/sparc64 (unregisterised is fine) -------------------------------------+------------------------------------- Reporter: zooko | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.11 (NCG) | Keywords: port sparc64 Resolution: | Architecture: sparc Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * os: OpenBSD => Unknown/Multiple * component: Compiler => Compiler (NCG) * architecture: Other => sparc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 23:22:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 23:22:51 -0000 Subject: [GHC] #9816: Add function for size-checked conversion of Integral types In-Reply-To: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> References: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> Message-ID: <057.9eee51d8827ac9649b345077c2a9a784@haskell.org> #9816: Add function for size-checked conversion of Integral types -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: D512 | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: core-libraries-committee@? (added) * component: libraries/base => Core Libraries Comment: We need a ruling from the Core Libraries Committee. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 23:26:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 23:26:38 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.1c0c466e08d74c9b33cb76d129d61c80@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: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Can someone try again with GHC 7.8.3, on OpenBSD? Note: [wiki:Building/Porting] mentions something about "--with-iconv- includes and --with-iconv-libraries". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 23:28:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 23:28:02 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.2ca549674eecab8e62c22d9cf13b534e@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: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #5666 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #5666 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 23:29:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 23:29:10 -0000 Subject: [GHC] #5666: Can't use writeFile to write unicode characters. In-Reply-To: <043.6e0e4a95f997e7dc06fe8203bd67272e@haskell.org> References: <043.6e0e4a95f997e7dc06fe8203bd67272e@haskell.org> Message-ID: <058.e266353da36d7d4e48ec94d760a7a0e0@haskell.org> #5666: Can't use writeFile to write unicode characters. -------------------------------------+------------------------------------- Reporter: tsou | Owner: ekmett Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.4.2 Libraries | Keywords: unicode writeFile Resolution: | Architecture: x86_64 (amd64) Operating System: OpenBSD | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #8118 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => infoneeded * related: => #8118 Comment: Can anyone on OpenBSD confirm this is still a problem with GHC 7.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 23:30:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 23:30:12 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.d3daf6b866579c715592f8c042482c1d@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: #9324 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): This check used to make GHCi way too fussy, but I'm quite happy with the current compromise (check is ignored when providing -ghci-script explicitly, or when user is root). Perhaps just improve the warning message to explain to the user exactly what is making GHCi unhappy and how to fix it? A umask of 002 only affects the default permissions, but it's easy enough for the user to chmod to something known to be safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 23:41:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 23:41:23 -0000 Subject: [GHC] #8114: STG lint panic (was: GHC panic when building `thyme`) In-Reply-To: <055.f8c8a84c7f414e985f0ca544eba21760@haskell.org> References: <055.f8c8a84c7f414e985f0ca544eba21760@haskell.org> Message-ID: <070.4dbe173bb729e5b9353ca5f435d922ee@haskell.org> #8114: STG lint panic -------------------------------------+------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #5345 time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #5345 Comment: Confirmed on Linux with ghc-7.9.20141115 using example from comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 20 23:50:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Nov 2014 23:50:57 -0000 Subject: [GHC] #8102: Parallel build of HEAD consistently fails In-Reply-To: <044.d6679f8dfedc0d08d438a0c928eb9fe9@haskell.org> References: <044.d6679f8dfedc0d08d438a0c928eb9fe9@haskell.org> Message-ID: <059.b70ce29547041cf11023c5f18bf052e7@haskell.org> #8102: Parallel build of HEAD consistently fails -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => fixed * milestone: 7.10.1 => Comment: The mentioned hack was added to the file `libraries/integer- gmp/mkGmpDerivedConstants/ghc.mk`, with a comment referring to this ticket. Since we are using `integer-gmp2` now, which doesn't have that file, I think we can close this ticket. Parallel builds do not consistenly fail anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 00:41:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 00:41:07 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.bbea1c693328f1b3ab0695851e6e54a2@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: 7.10.1 Priority: high | Version: 7.6.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 5321 Type of failure: Compile- | time performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high * milestone: => 7.10.1 Comment: Running the first example from the description with ghc HEAD: {{{ $ ./Types 200 a a > test.hs && ghc-7.9.20141119 test.hs > /dev/null -fcontext-stack=250 +RTS -t test.hs:12:10: Type function application stack overflow; size = 201 Use -ftype-function-depth=N to increase stack size to N Replicate1 'Zero () ~ '[] In the instance declaration for ?Class (Data xs)? <> }}} That's a lot of bytes. Adding `-ftype-function-depth=250` doesn't help: ever increasing memory usage until I have to kill the process. I did not try any of the other examples. This looks like a regression, setting priority to high. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 00:47:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 00:47:02 -0000 Subject: [GHC] #8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8 In-Reply-To: <046.b62b3553268043815d7b86071673cb91@haskell.org> References: <046.b62b3553268043815d7b86071673cb91@haskell.org> Message-ID: <061.51812c0e824448eaf9f8fcdf6c65dc7a@haskell.org> #8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8 ----------------------------------------+---------------------------------- Reporter: rampion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Can someone on Mac OS X 64-bit verify that `ghc -e` works now, with ghc 7.8.3 (haskell platform 2014.02). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 00:48:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 00:48:11 -0000 Subject: [GHC] #8093: Runtime Internal Error with setNumCapabilities 1 In-Reply-To: <044.b978e45ccab477a8d41762af6fc0f487@haskell.org> References: <044.b978e45ccab477a8d41762af6fc0f487@haskell.org> Message-ID: <059.165d6ebb62a664fbd0f1fbdb485ea7d6@haskell.org> #8093: Runtime Internal Error with setNumCapabilities 1 -----------------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------- Changes (by thomie): * cc: simonmar (added) * status: infoneeded => closed * resolution: => worksforme Comment: No response from submitter: closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 00:54:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 00:54:35 -0000 Subject: [GHC] #8085: Both GHC and its installer don't run on current Debian Stable In-Reply-To: <044.950a7a72a7ff9aabb202da185a28c46e@haskell.org> References: <044.950a7a72a7ff9aabb202da185a28c46e@haskell.org> Message-ID: <059.bfede0116fc9f73604b6dfab9a883f9a@haskell.org> #8085: Both GHC and its installer don't run on current Debian Stable -------------------------------------+------------------------------------- Reporter: ppetr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Installing | Difficulty: Easy (less than 1 GHC failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: GHC doesn't work at all => Installing GHC failed * resolution: => fixed Comment: Check out http://deb.haskell.org/ for GHC Debian packages. Please re-open this ticket if there are still problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 02:36:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 02:36:05 -0000 Subject: [GHC] #8068: ghc incorrectly accepts the Kannada TTHA character at the beginning of an identifier. In-Reply-To: <047.e9d4cfb77ac784c38c71bdecc757e158@haskell.org> References: <047.e9d4cfb77ac784c38c71bdecc757e158@haskell.org> Message-ID: <062.54ee7f47d5a9a02b239975e5afd943f7@haskell.org> #8068: ghc incorrectly accepts the Kannada TTHA character at the beginning of an identifier. -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1103 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix * related: => #1103 Comment: This was a conscious decision, see commit 0c266d7ac54ae27e693ef04e4679220a32da0694. {{{ Author: Simon Marlow <> Date: Wed Jul 9 09:12:52 2008 +0000 Treat the Unicode "Letter, Other" class as lowercase letters (#1103) This is an arbitrary choice, but it's strictly more useful than the current situation, where these characters cannot be used in identifiers at all. In Haskell' we may revisit this decision (it's on my list of things to discuss), but for now this is an improvement for those using caseless languages. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 02:49:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 02:49:03 -0000 Subject: [GHC] #8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8 In-Reply-To: <046.b62b3553268043815d7b86071673cb91@haskell.org> References: <046.b62b3553268043815d7b86071673cb91@haskell.org> Message-ID: <061.0f54b7c15a814afbd2f314d966390930@haskell.org> #8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8 ----------------------------------------+---------------------------------- Reporter: rampion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by Ptharien's Flame): It seems to work just fine for me, although I don't know how much of a stress test my normal development workflow is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 02:59:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 02:59:23 -0000 Subject: [GHC] #8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8 In-Reply-To: <046.b62b3553268043815d7b86071673cb91@haskell.org> References: <046.b62b3553268043815d7b86071673cb91@haskell.org> Message-ID: <061.26ce1526e144c95de8eb68b7c8d674ed@haskell.org> #8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8 ----------------------------------------+---------------------------------- Reporter: rampion | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Thanks for the input, let's close this then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 03:06:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 03:06:14 -0000 Subject: [GHC] #3283: Selective disabling of unused bind warnings In-Reply-To: <042.99c53619193c24de1883dd2c0ccb355d@haskell.org> References: <042.99c53619193c24de1883dd2c0ccb355d@haskell.org> Message-ID: <057.114d21dc393a2c86bb46e4ca513b0548@haskell.org> #3283: Selective disabling of unused bind warnings -------------------------------------+------------------------------------- Reporter: ajd | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.10.2 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #17 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: Adding newcomer keyword at nomeata's suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 03:28:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 03:28:23 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.b83462ee62772db5065af3139eea7c73@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D510 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"6efe5729252ea50843e1b04e21c7a3e1769a3434/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6efe5729252ea50843e1b04e21c7a3e1769a3434" Don't build old-{time,locale} and haskell{98,2010} Summary: As discussed on ghc-devs at haskell.org and the trac ticket, we're removing these packages from the 7.10 release as they no longer work correctly, and can't easily be made to properly follow the standard as `base` changes over time. This does not remove the packages from the tree, only the build system. https://www.haskell.org/pipermail/ghc-devs/2014-November/007357.html Signed-off-by: Austin Seipp Test Plan: iiam Reviewers: hvr, ekmett Reviewed By: hvr, ekmett Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D510 GHC Trac Issues: #9590 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 03:32:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 03:32:55 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.520153787fa926a386dfeeba372a611e@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D510 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"86dda8f7adb887eb376a938dd48780e503b53a08/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="86dda8f7adb887eb376a938dd48780e503b53a08" Delete old-{time,locale} and haskell{98,2010} Summary: Depends on D510. This is the final blow and removes them from the tree completely. Signed-off-by: Austin Seipp Test Plan: I looked really hard but didn't see them. Reviewers: hvr, ekmett Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D511 GHC Trac Issues: #9590 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 03:35:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 03:35:24 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.72f3802b0401d902ae7f2986b0bb4dca@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: AMP Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D510 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 04:43:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 04:43:52 -0000 Subject: [GHC] #9368: Add strictly accumulating scanl' to Data.List In-Reply-To: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> References: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> Message-ID: <060.08fe1562b251ca993764ba4e74061288@haskell.org> #9368: Add strictly accumulating scanl' to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9345 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D498 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"f60eeb41ab48e73ea49fba64a745ddc4a6b8c085/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f60eeb41ab48e73ea49fba64a745ddc4a6b8c085" Export scanl' from Data.OldList and Data.List Summary: Fixes #9368 Reviewers: nomeata, hvr, ekmett, austin Reviewed By: ekmett, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D498 GHC Trac Issues: #9368 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 04:43:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 04:43:52 -0000 Subject: [GHC] #2526: Warn about missing signatures only for exported functions In-Reply-To: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> References: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> Message-ID: <069.be130b687ca6126f79dd20b43d163c91@haskell.org> #2526: Warn about missing signatures only for exported functions -------------------------------------+------------------------------------- Reporter: | Owner: gridaphobe fergushenderson | Status: new Type: feature | Milestone: 7.10.1 request | Version: 6.8.3 Priority: lowest | Keywords: newcomer Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"067f1e4f20efc824badbac54da2f9484090cb39b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="067f1e4f20efc824badbac54da2f9484090cb39b" Add flag `-fwarn-missing-exported-sigs` Summary: add `-fwarn-missing-exported-sigs` to only warn about missing signatures if the name is exported Test Plan: validate, see testsuite/tests/warnings/should_compile/T2526.hs Reviewers: ezyang, austin, thomie Reviewed By: austin, thomie Subscribers: ezyang, thomie, carter Differential Revision: https://phabricator.haskell.org/D482 GHC Trac Issues: #2526 Conflicts: docs/users_guide/7.10.1-notes.xml }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 04:43:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 04:43:52 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.19ceb0d2b0a91cdebc9644af4d632da8@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7ed482d909556c1b969185921e27e3fe30c2fe86/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7ed482d909556c1b969185921e27e3fe30c2fe86" Implement #5462 (deriving clause for arbitrary classes) Summary: (this has been submitted on behalf on @dreixel) Reviewers: simonpj, hvr, austin Reviewed By: simonpj, austin Subscribers: goldfire, thomie, carter, dreixel Differential Revision: https://phabricator.haskell.org/D476 GHC Trac Issues: #5462 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 04:44:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 04:44:26 -0000 Subject: [GHC] #9368: Add strictly accumulating scanl' to Data.List In-Reply-To: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> References: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> Message-ID: <060.518b77bd8e07c5604ac7fdf6ce61d5d3@haskell.org> #9368: Add strictly accumulating scanl' to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9345 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D498 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 04:45:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 04:45:11 -0000 Subject: [GHC] #2526: Warn about missing signatures only for exported functions In-Reply-To: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> References: <054.8d84f54fed1e47316e9d59e9281759fd@haskell.org> Message-ID: <069.cf77ce03732c4d455ef588e21621947e@haskell.org> #2526: Warn about missing signatures only for exported functions -------------------------------------+------------------------------------- Reporter: | Owner: gridaphobe fergushenderson | Status: closed Type: feature | Milestone: 7.10.1 request | Version: 6.8.3 Priority: lowest | Keywords: newcomer Component: Compiler | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 05:14:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 05:14:45 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.b11a2190ec423c97feb0de517153f03b@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by lukexi): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 05:15:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 05:15:12 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.23271f4e805c02f92639f0cf405c2504@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by lukexi): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 05:48:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 05:48:13 -0000 Subject: [GHC] #9817: signal handlers in unix are passed garbage when using the signle threaded rts Message-ID: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> #9817: signal handlers in unix are passed garbage when using the signle threaded rts -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` struct that was originally passed to the underlying os signal handler. Unfortunately, this only seems to work correctly in the threaded rts. In the single-threaded rts, the buffer contains garbage. This can be demonstrated by the following program: {{{#!hs import Control.Concurrent import System.Posix.Signals main :: IO () main = do wait <- newEmptyMVar _ <- flip (installHandler sig) Nothing $ CatchInfo $ \info -> do putStrLn $ "Received a signal " ++ show (siginfoSignal info) putMVar wait () raiseSignal sig putStrLn $ "Sending myself a signal " ++ show sig takeMVar wait where sig = sigUSR2 }}} If you compile the program with the `-threaded` flag then everything works just fine: {{{ Sending myself a signal 12 Received a signal 12 }}} but without it, the signal handler will print a totaly random signal number: {{{ Sending myself a signal 12 Received a signal 138644296 }}} I was able to track this down to the function `startSignalHandlers` in `rts/posix/Signals.c`. This function (which is only used by the single threaded rts) allocates a buffer and copies the `siginfo_t` struct to it and then schedules `GHC.Conc.Signal.runHandlers` to be run in a new thread. The problem is that while `GHC.Conc.Signal.runHandlers` expects a `ForeignPtr Word8`, here it is given a `Ptr Word8`. This has two implications: the signal handler is given invalid data, and nobody is deallocating the buffer so we are leaking memory every time a signal is received that has a custom handler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 06:00:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 06:00:12 -0000 Subject: [GHC] #9817: signal handlers in unix are passed garbage when using the signle threaded rts In-Reply-To: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> References: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> Message-ID: <060.62e2220a48454c8e30d91eda7983cacc@haskell.org> #9817: signal handlers in unix are passed garbage when using the signle threaded rts -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D515 | -------------------------------------+------------------------------------- Changes (by redneb): * differential: => Phab:D515 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 06:04:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 06:04:35 -0000 Subject: [GHC] #9817: signal handlers in unix are passed garbage when using the signle threaded rts In-Reply-To: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> References: <045.646b26d4129c0e58f98ff89c628f56b1@haskell.org> Message-ID: <060.ff99f1fd4bd38e9cc9322d176d6ef2c5@haskell.org> #9817: signal handlers in unix are passed garbage when using the signle threaded rts -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D515 | -------------------------------------+------------------------------------- Changes (by redneb): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 06:50:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 06:50:45 -0000 Subject: [GHC] #9816: Add function for size-checked conversion of Integral types In-Reply-To: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> References: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> Message-ID: <057.d547adbf7687a82d3dcec68098f17266@haskell.org> #9816: Add function for size-checked conversion of Integral types -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: D512 | -------------------------------------+------------------------------------- Description changed by spl: Old description: > Based on the discussion in > [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23338 this > thread], I would like to add a function to the {{{base}}} library that is > similar to {{{fromIntegral}}} but only successful if the argument fits in > the result type. > > If possible, I would like to get this into 7.10. My apologies for running > late on it. Hopefully, since it is a relatively small change overall, the > "only" controversy will be bikeshedding. > > I have concluded that adding @hvr's {{{intCastMaybe}}} from > [http://hackage.haskell.org/package/int-cast int-cast] is the best > possible option. Previously, I thought a {{{Bounded}}}-based version was > also useful; however, I realized that it did not deal properly with > conversions like {{{Int<->Word}}}/{{{Int8<->Word8}}}/etc. as well as > {{{intCastMaybe}}} and would need specialized versions that > {{{intCastMaybe}}} provides automatically. New description: Based on the discussion in [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23338 this thread], I would like to add a function to the {{{base}}} library that is similar to {{{fromIntegral}}} but only successful if the argument fits in the result type. If possible, I would like to get this into 7.10. My apologies for running late on it. Hopefully, since it is a relatively small change overall, the "only" controversy will be bikeshedding. I have concluded that adding @hvr's {{{intCastMaybe}}} from [http://hackage.haskell.org/package/int-cast int-cast] is the best possible option. Previously, I thought a {{{Bounded}}}-based version was also useful; however, I realized that it did not deal optimally with conversions like {{{Int<->Word}}}/{{{Int8<->Word8}}}/etc. as well as {{{intCastMaybe}}} does and would need specialized versions that {{{intCastMaybe}}} provides automatically. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 07:18:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 07:18:19 -0000 Subject: [GHC] #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" In-Reply-To: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> References: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> Message-ID: <060.03021a1512b619a2d477bf9c9dd48b50@haskell.org> #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" -------------------------------------+------------------------------------- Reporter: jfeltz | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: :set -XCPP | followed by :unset -XCPP | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by leroux): * owner: => leroux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 07:51:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 07:51:23 -0000 Subject: [GHC] #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" In-Reply-To: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> References: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> Message-ID: <060.3247e6af280393d2fae74d4fef4ef1a3@haskell.org> #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" -------------------------------------------+---------------------------- Reporter: jfeltz | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: T9293 | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+---------------------------- Changes (by leroux): * testcase: :set -XCPP followed by :unset -XCPP => T9293 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 08:02:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 08:02:05 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` Message-ID: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #3650 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- See original proposal at http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23300 which was generally met with unanimous support for adding such a type. Request for CLC-arbitration (and its conclusion) on two more or less controversial details lacking consensus: https://groups.google.com/forum/#!msg/haskell-core- libraries/CVylSkkHCWE/Cqn7VEgR24sJ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 08:02:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 08:02:36 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types Message-ID: <050.b04515eaa5272881d87195907090dfe3@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Say I have a class like the following: {{{#!hs class IntLike a where fromInt :: Int -> a toInt :: a -> Int }}} There should be a typesafe, principled way to get the dictionary type created from buildClass in compiler/iface/BuildTyCl.lhs like such (in this hypothetical, using a type family: {{{#!hs plusN :: (IntLike a) => Int -> Dictionary (IntLike a) }}} It would be nice if the type family was injective, if it was implemented in such a way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 08:02:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 08:02:37 -0000 Subject: [GHC] #3650: Add a Natural number type to the pre-defined basic types. In-Reply-To: <044.8f2b020c1c43231e9e02b324d5f95775@haskell.org> References: <044.8f2b020c1c43231e9e02b324d5f95775@haskell.org> Message-ID: <059.e53a728420640de58e49f76dda839b1b@haskell.org> #3650: Add a Natural number type to the pre-defined basic types. -------------------------------------+------------------------------------- Reporter: JohnD | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: Compiler | Version: (Type checker) | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9818 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * difficulty: => Unknown * related: => #9818 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 08:04:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 08:04:13 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.0382c3255fbdd8d7e2d38942a2e4afb3@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) * keywords: => base natural * differential: => Phab:D473 * component: Compiler => Core Libraries * owner: => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 08:23:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 08:23:27 -0000 Subject: [GHC] #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" In-Reply-To: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> References: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> Message-ID: <060.a652c879935eee5685e762bdb7ac6cc8@haskell.org> #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" -------------------------------------------+---------------------------- Reporter: jfeltz | Owner: leroux Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: T9293 | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D516 | -------------------------------------------+---------------------------- Changes (by leroux): * status: new => patch * differential: => Phab:D516 Comment: Patch that essentially rewrites {{{:unset -X}}} to {{{:set -XNo}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 09:16:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 09:16:39 -0000 Subject: [GHC] #8085: Both GHC and its installer don't run on current Debian Stable In-Reply-To: <044.950a7a72a7ff9aabb202da185a28c46e@haskell.org> References: <044.950a7a72a7ff9aabb202da185a28c46e@haskell.org> Message-ID: <059.398768c62822444ad612dead0513e67e@haskell.org> #8085: Both GHC and its installer don't run on current Debian Stable -------------------------------------+------------------------------------- Reporter: ppetr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Installing | Difficulty: Easy (less than 1 GHC failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Well, the ticket was not about making Debian packages (these were present when the ticked was opened) but about the builds available from GHC website. Still I think this is now fixed - we have builds for Debian 7 available for download. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 09:34:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 09:34:18 -0000 Subject: [GHC] #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances Message-ID: <047.146348de4d2b18e1ad0360b7562542c2@haskell.org> #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This report is inspired by http://stackoverflow.com/questions/27051640 /strange-behavior-when-adding-constraint-to-instance I'm not sure if it is a bug, but it certainly feels strange and inconsistent to me, so I'd like to get some clarification. Here's a self-contained example of the behaviour: {{{#!hs {-# LANGUAGE FlexibleInstances, OverlappingInstances #-} module Overlap where class C a where foo :: a -> a instance C a where foo = id instance C Int where foo = (+1) -- Note that this one does not mention class C anywhere: class D a where bar :: a -> a instance D a where bar = foo -- this works and picks the 'C a' instance always -- The following does not compile without IncoherentInstances: {- baz :: a -> a baz = foo -} }}} I'm surprised that the definitions of `bar` and `baz` are treated differently. Shouldn't they either both require `IncoherentInstances`, or both work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 09:35:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 09:35:00 -0000 Subject: [GHC] #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances In-Reply-To: <047.146348de4d2b18e1ad0360b7562542c2@haskell.org> References: <047.146348de4d2b18e1ad0360b7562542c2@haskell.org> Message-ID: <062.a4047ad10dd9d655d3a696467558f43e@haskell.org> #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by kosmikus): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 09:51:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 09:51:15 -0000 Subject: [GHC] #9821: DeriveAnyClass support for higher-kinded classes + some more comments Message-ID: <046.bafe3d4d92de807a1dcd92a0f60cb2fa@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #5462 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- #5462 was merged before a few final fixes were done. This ticket serves to record that. Left to address are: https://phabricator.haskell.org/D476?id=1443#inline-3652 https://phabricator.haskell.org/D476?id=1443#inline-3648 https://phabricator.haskell.org/D476?id=1443#inline-3646 Also, `DeriveAnyClass` currently panics at higher-kinded classes (like `((* -> *) -> *) -> Constraint`). I'll fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 10:31:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 10:31:25 -0000 Subject: [GHC] #9822: Add displayException to Exception typeclass Message-ID: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> #9822: Add displayException to Exception typeclass -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Discussed on the libraries list at: https://www.haskell.org/pipermail/libraries/2014-November/024176.html I am only implementing part (1) of this proposal due to lack of consensus on part (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 10:41:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 10:41:08 -0000 Subject: [GHC] #9822: Add displayException to Exception typeclass In-Reply-To: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> References: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> Message-ID: <062.fc4faa26b5e5be1f038e08a39d6d790a@haskell.org> #9822: Add displayException to Exception typeclass -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by snoyberg): * version: 7.9 => * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 10:59:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 10:59:03 -0000 Subject: [GHC] #9822: Add displayException to Exception typeclass In-Reply-To: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> References: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> Message-ID: <062.da57216d8300f4e515e8ab140e4e4421@haskell.org> #9822: Add displayException to Exception typeclass -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): Phabricator link: https://phabricator.haskell.org/D517 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 11:23:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 11:23:09 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.9ecdb0963ca0f610ba59403c0b57ed70@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T9569, typecheck/should_compile/T9569a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 12:50:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 12:50:59 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.51d2d1672f40883dde63724c1aba1065@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm sorry, but I don't understand your request. The dictionary for `IntLike` would look something like this: {{{ data IntLikeDict a = MkIntLikeDict { fromInt :: Int -> a ; toInt :: a -> Int } }}} There isn't an actual number stored anywhere. And, in fact, my example has made things more complicated than they really are. The dictionary type within GHC '''is''' `IntLike` -- there's no separate dictionary type. Is `Dict` what you're looking for? {{{ data Dict c where Dict :: c => Dict c }}} That's definable today with !ConstraintKinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:02:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:02:51 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.7275e4f3e4c2d99190280824bf307da8@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b6855422fd532e5988fc98764c5cc47acbefbfb8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b6855422fd532e5988fc98764c5cc47acbefbfb8" Implement full co/contra-variant subsumption checking (fixes Trac #9569) This is a pretty big patch, but which substantially iproves the subsumption check. Trac #9569 was the presenting example, showing how type inference could depend rather delicately on eta expansion. But there are other less exotic examples; see Note [Co/contra-variance of subsumption checking] in TcUnify. The driving change is to TcUnify.tcSubType. But also * HsWrapper gets a new constructor WpFun, which behaves very like CoFun: if wrap1 :: exp_arg <= act_arg wrap2 :: act_res <= exp_res then WpFun wrap1 wrap2 : (act_arg -> arg_res) <= (exp_arg -> exp_res) * I generalised TcExp.tcApp to call tcSubType on the result, rather than tcUnifyType. I think this just makes it consistent with everything else, notably tcWrapResult. As usual I ended up doing some follow-on refactoring * AmbigOrigin is gone (in favour of TypeEqOrigin) * Combined BindPatSigCtxt and PatSigCxt into one * Improved a bit of error message generation }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:02:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:02:51 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions In-Reply-To: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> References: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> Message-ID: <062.99f7a33faac4e25b3f30eb867fbb05fa@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T9318 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5760eb598e0dfa451407195f15072204c15233ed/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5760eb598e0dfa451407195f15072204c15233ed" Test Trac #9318 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:02:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:02:51 -0000 Subject: [GHC] #9222: Unexpected DataKind Panic In-Reply-To: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> References: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> Message-ID: <060.dca34decf7af03c7c1403319ec708fec@haskell.org> #9222: Unexpected DataKind Panic --------------------------------------------+------------------------------ Reporter: ekmett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T9222 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"b82410ab8908f1ec2a6aa14cce62948c92bcbce9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b82410ab8908f1ec2a6aa14cce62948c92bcbce9" Trac #9222 is actually an ambiguous type, now detected }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:02:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:02:51 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.a901c2c86e80eed94dcf27655ee69315@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"230b013b654508f77c5d8cec9d4de9b7c86e1370/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="230b013b654508f77c5d8cec9d4de9b7c86e1370" Test Trac #9569 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:02:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:02:51 -0000 Subject: [GHC] #7220: Confusing error message in type checking related to type family, fundep, and higher-rank type In-Reply-To: <047.9717070c95e8f3c062d13d9d4af61725@haskell.org> References: <047.9717070c95e8f3c062d13d9d4af61725@haskell.org> Message-ID: <062.d1e6e70b07cffbba66ef313bbba3e1f8@haskell.org> #7220: Confusing error message in type checking related to type family, fundep, and higher-rank type -------------------------------------+------------------------------------- Reporter: tsuyoshi | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1-rc1 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T7220 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7b1a8562d9b92547251d0dff23bb3a2de25d4b6f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7b1a8562d9b92547251d0dff23bb3a2de25d4b6f" Fix up tests for Trac #7220; the old test really was ambiguous }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:02:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:02:52 -0000 Subject: [GHC] #8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported In-Reply-To: <046.2c433f8cbc6c486af267486ff9ed1e9c@haskell.org> References: <046.2c433f8cbc6c486af267486ff9ed1e9c@haskell.org> Message-ID: <061.46c03d10c1f5bc4548bde5e14f3cd5ec@haskell.org> #8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c5a39389ea067b2932961a27f5e4c28e135cf266/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c5a39389ea067b2932961a27f5e4c28e135cf266" Test Trac #8149 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:02:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:02:51 -0000 Subject: [GHC] #9815: Runtime error with RecordWildCards and a non-record constructor In-Reply-To: <043.28b061d1b50c39a8e997a8d356845e54@haskell.org> References: <043.28b061d1b50c39a8e997a8d356845e54@haskell.org> Message-ID: <058.fa574e518cbb0055448d83a7e9cfc978@haskell.org> #9815: Runtime error with RecordWildCards and a non-record constructor -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: RecordWildCards, Resolution: | warning Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4ba4cc7aaaf2bff31bc8474c8ba40e1cbe3e3875/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4ba4cc7aaaf2bff31bc8474c8ba40e1cbe3e3875" Fix Trac #9815 Dot-dot record-wildcard notation is simply illegal for constructors without any named fields, but that was neither documented nor checked. This patch does so - Make the check in RnPat - Add test T9815 - Fix CmmLayoutStack which was using the illegal form (!) - Document in user manual }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:04:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:04:23 -0000 Subject: [GHC] #9569: Tuple constraints don't work right In-Reply-To: <046.31f45b75873be125a1cc8887558fe856@haskell.org> References: <046.31f45b75873be125a1cc8887558fe856@haskell.org> Message-ID: <061.7093a667ec1ceb2d5f07387d67c3e66b@haskell.org> #9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9569, | typecheck/should_compile/T9569a | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Ha! Fixed at last. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:04:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:04:46 -0000 Subject: [GHC] #8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported In-Reply-To: <046.2c433f8cbc6c486af267486ff9ed1e9c@haskell.org> References: <046.2c433f8cbc6c486af267486ff9ed1e9c@haskell.org> Message-ID: <061.ddea8646c48ff10c8663c5bc464005e6@haskell.org> #8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Indeed, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:07:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:07:11 -0000 Subject: [GHC] #9815: Runtime error with RecordWildCards and a non-record constructor In-Reply-To: <043.28b061d1b50c39a8e997a8d356845e54@haskell.org> References: <043.28b061d1b50c39a8e997a8d356845e54@haskell.org> Message-ID: <058.781c98c0a52b187dc35a455c8fafc50f@haskell.org> #9815: Runtime error with RecordWildCards and a non-record constructor -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: RecordWildCards, Resolution: fixed | warning Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | rename/should_fail/T9815 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => rename/should_fail/T9815 * resolution: => fixed Comment: Excellent point, thank you. Now fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:08:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:08:50 -0000 Subject: [GHC] #8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported In-Reply-To: <046.2c433f8cbc6c486af267486ff9ed1e9c@haskell.org> References: <046.2c433f8cbc6c486af267486ff9ed1e9c@haskell.org> Message-ID: <061.43f67ae2a98943e5b4b250c7095fa8d8@haskell.org> #8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | rename/should_fail/T8149 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T8149 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:39:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:39:05 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions In-Reply-To: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> References: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> Message-ID: <062.522c25a0cea18117ff344298ab57ef0a@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T9318 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Looks like we both did this, albeit in different places... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 13:49:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 13:49:14 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions In-Reply-To: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> References: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> Message-ID: <062.22a971d6723d83d79a4bc68886984fed@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T9318 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh yes...ha ha. Can you delete one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 14:09:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 14:09:58 -0000 Subject: [GHC] #9823: --show-iface panics with HEAD Message-ID: <048.f88fb01b9c0230c2f81d0f8e88c01d42@haskell.org> #9823: --show-iface panics with HEAD -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Driver | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: GHC than a day) | doesn't work at all Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Let's say I compile an empty module: {{{#!hs module Foo where }}} Now, this works: {{{ ghc-stage2 --show-iface Foo.hi }}} But this panics: {{{ ghc-stage2 Foo.hi --show-iface ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141120 for x86_64-unknown-linux): ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141120 for x86_64-unknown-linux): v_unsafeGlobalDynFlags: not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Does not happen with 7.8.3. I guess one of recent DynFlags changes must have caused this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 14:13:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 14:13:29 -0000 Subject: [GHC] #9823: --show-iface panics with HEAD In-Reply-To: <048.f88fb01b9c0230c2f81d0f8e88c01d42@haskell.org> References: <048.f88fb01b9c0230c2f81d0f8e88c01d42@haskell.org> Message-ID: <063.58f2da56929455e978246a1d84075d34@haskell.org> #9823: --show-iface panics with HEAD -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Driver | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: GHC | than a day) doesn't work at all | Blocked By: Test Case: | Related Tickets: #9799 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9799 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 14:13:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 14:13:59 -0000 Subject: [GHC] #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" In-Reply-To: <045.33b56a4389644150958519a6a326156f@haskell.org> References: <045.33b56a4389644150958519a6a326156f@haskell.org> Message-ID: <060.145b17f28873679f27bbd7ebe71941b6@haskell.org> #9799: ghci -e panic "v_unsafeGlobalDynFlags: not initialised" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: #9360, Blocking: | #9259,#9823 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #9360, #9259 => #9360, #9259,#9823 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 15:17:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 15:17:40 -0000 Subject: [GHC] #9822: Add displayException to Exception typeclass In-Reply-To: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> References: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> Message-ID: <062.227eb670f5062cec5978d3442a8d5054@haskell.org> #9822: Add displayException to Exception typeclass -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D517 | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) * keywords: => base * differential: => Phab:D517 * component: libraries/base => Core Libraries * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 15:29:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 15:29:23 -0000 Subject: [GHC] #9824: Pattern quotations warn about unused matches Message-ID: <047.5d2a5cd8668339c26227f5e3e81864a7@haskell.org> #9824: Pattern quotations warn about unused matches -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -fwarn-unused-matches #-} module Pat where foo = [p| (x, y) |] }}} I get {{{ Pat.hs:6:12: Warning: Defined but not used: ?x? Pat.hs:6:15: Warning: Defined but not used: ?y? }}} This is silly. Patch forthcoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:17 -0000 Subject: [GHC] #7484: Template Haskell allows building invalid record fields/names In-Reply-To: <045.397b38fee58f310a634c2d78baa84281@haskell.org> References: <045.397b38fee58f310a634c2d78baa84281@haskell.org> Message-ID: <060.ac85aa17aca3f2d5703ed4938e9b7764@haskell.org> #7484: Template Haskell allows building invalid record fields/names -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8750 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D431 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"dbf360a5264d5d6597e046dcd9b4f49effa91eee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dbf360a5264d5d6597e046dcd9b4f49effa91eee" Test #7484 in th/T7484 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:17 -0000 Subject: [GHC] #7484: Template Haskell allows building invalid record fields/names In-Reply-To: <045.397b38fee58f310a634c2d78baa84281@haskell.org> References: <045.397b38fee58f310a634c2d78baa84281@haskell.org> Message-ID: <060.dc97537caa0d2a5a3239ca1831fa40fa@haskell.org> #7484: Template Haskell allows building invalid record fields/names -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8750 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D431 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"da2fca9e2be8c61c91c034d8c2302d8b1d1e7b41/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="da2fca9e2be8c61c91c034d8c2302d8b1d1e7b41" Fix #7484, checking for good binder names in Convert. This commit also refactors a bunch of lexeme-oriented code into a new module Lexeme, and includes a submodule update for haddock. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:17 -0000 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> Message-ID: <059.477401db7c9042d15d792d1b2427137d@haskell.org> #1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"adb20a0aec89047af397ef8c3fcde78217e6e5f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="adb20a0aec89047af397ef8c3fcde78217e6e5f6" Test #1476 in th/T1476 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:17 -0000 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> Message-ID: <059.b0a3dbbd6e7f956ad668fed226bf9bfc@haskell.org> #1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d627c5cf81fcce05ec160edc5be907297ff05c33/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d627c5cf81fcce05ec160edc5be907297ff05c33" Test that nested pattern splices don't scope (#1476). Test case: th/T1476b. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:17 -0000 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> Message-ID: <059.31c1aa4bf2745b5766d7a6b60214f186@haskell.org> #1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2346de44330a4309b840e26ddd1ded23f92c6f81/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2346de44330a4309b840e26ddd1ded23f92c6f81" Fix #1476 by making splice patterns work. Unfortunately, splice patterns in brackets still do not work because we don't run splices in brackets. Without running a pattern splice, we can't know what variables it binds, so we're stuck. This is still a substantial improvement, and it may be the best we can do. Still must document new behavior. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:17 -0000 Subject: [GHC] #7484: Template Haskell allows building invalid record fields/names In-Reply-To: <045.397b38fee58f310a634c2d78baa84281@haskell.org> References: <045.397b38fee58f310a634c2d78baa84281@haskell.org> Message-ID: <060.8a8d67f38800fe703d3ea1a939e58125@haskell.org> #7484: Template Haskell allows building invalid record fields/names -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8750 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D431 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1b22d9f288cbf819be90ec42b254fb1b67dded2d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1b22d9f288cbf819be90ec42b254fb1b67dded2d" Release notes for #1476, #7484. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:17 -0000 Subject: [GHC] #9824: Pattern quotations warn about unused matches In-Reply-To: <047.5d2a5cd8668339c26227f5e3e81864a7@haskell.org> References: <047.5d2a5cd8668339c26227f5e3e81864a7@haskell.org> Message-ID: <062.6f9c3584f81387544a9a0260c97173e4@haskell.org> #9824: Pattern quotations warn about unused matches -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"3b3944f9a1cf7d89dccf742d7449402cca31ba5a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3b3944f9a1cf7d89dccf742d7449402cca31ba5a" Test #9824 in th/T9824 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:17 -0000 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> Message-ID: <059.1233ef3039008176da5126e8d2142c02@haskell.org> #1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1b22d9f288cbf819be90ec42b254fb1b67dded2d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1b22d9f288cbf819be90ec42b254fb1b67dded2d" Release notes for #1476, #7484. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:18 -0000 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> Message-ID: <059.77a07d8be63f51ebf040c0e237697e6d@haskell.org> #1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"cfa574cea30b411080de5d641309bdf135ed9be5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cfa574cea30b411080de5d641309bdf135ed9be5" Update manual for pattern splices (#1476) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:18:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:18:18 -0000 Subject: [GHC] #9824: Pattern quotations warn about unused matches In-Reply-To: <047.5d2a5cd8668339c26227f5e3e81864a7@haskell.org> References: <047.5d2a5cd8668339c26227f5e3e81864a7@haskell.org> Message-ID: <062.903780bdf27387edecedad40ca46fa91@haskell.org> #9824: Pattern quotations warn about unused matches -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"bc05354949dce9d3b56353d3310eb9804d4e17f5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bc05354949dce9d3b56353d3310eb9804d4e17f5" Fix #9824 by not warning about unused matches in pattern quotes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:23:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:23:08 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.d6a16085d5a40b5527650947aceda694@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 16:38:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 16:38:05 -0000 Subject: [GHC] #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances In-Reply-To: <047.146348de4d2b18e1ad0360b7562542c2@haskell.org> References: <047.146348de4d2b18e1ad0360b7562542c2@haskell.org> Message-ID: <062.fd0754af92d17771e550b8f6831dd8eb@haskell.org> #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:04:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:04:53 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.5b028cbf3fbcd7c648b0e9899cc2e599@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Yuras): * priority: low => normal * difficulty: => Unknown Comment: The compile time check (introduced in a278f3f02d09bc32b0a75d4a04d710090cde250f) was removed when replacing the old code generator. So now it crashes at runtime again. It was report a number of times, see #9647 and #8568. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:08:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:08:13 -0000 Subject: [GHC] #9647: allocation of 10790760 bytes too large In-Reply-To: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> References: <044.ea008477adc27377b0bfb900ee1ed003@haskell.org> Message-ID: <059.0ccbaf8e3b8d948ea1b28dd6551ab945@haskell.org> #9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: run time Operating System: | insufficient memory Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: #8568 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Yuras): * status: new => closed * resolution: => duplicate Comment: Seems to be a duplicate of #4505. Please reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:08:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:08:53 -0000 Subject: [GHC] #8568: internal error: allocation of ... bytes too large In-Reply-To: <047.44f15a8730cfbfb111ae73ca03abf808@haskell.org> References: <047.44f15a8730cfbfb111ae73ca03abf808@haskell.org> Message-ID: <062.a9b99c5ff9a1450013d516bec8ad8308@haskell.org> #8568: internal error: allocation of ... bytes too large -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #9647 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Yuras): * status: new => closed * resolution: => duplicate Comment: Seems to be a duplicate of #4505. Please reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:25:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:25:48 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.130a01e6b67cf51578d614ec69b15bb1@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"803fc5db31f084b73713342cdceaed5a9c664267/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="803fc5db31f084b73713342cdceaed5a9c664267" Add API Annotations Summary: The final design and discussion is captured at https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations This is a proof of concept implementation of a completely separate annotation structure, populated in the parser,and tied to the AST by means of a virtual "node-key" comprising the surrounding SrcSpan and a value derived from the specific constructor used for the node. The key parts of the design are the following. == The Annotations == In `hsSyn/ApiAnnotation.hs` ```lang=haskell type ApiAnns = (Map.Map ApiAnnKey SrcSpan, Map.Map SrcSpan [Located Token]) type ApiAnnKey = (SrcSpan,AnnKeywordId) -- --------------------------------------------------------------------- -- | Retrieve an annotation based on the @SrcSpan@ of the annotated AST -- element, and the known type of the annotation. getAnnotation :: ApiAnns -> SrcSpan -> AnnKeywordId -> Maybe SrcSpan getAnnotation (anns,_) span ann = Map.lookup (span,ann) anns -- |Retrieve the comments allocated to the current @SrcSpan@ getAnnotationComments :: ApiAnns -> SrcSpan -> [Located Token] getAnnotationComments (_,anns) span = case Map.lookup span anns of Just cs -> cs Nothing -> [] -- | Note: in general the names of these are taken from the -- corresponding token, unless otherwise noted data AnnKeywordId = AnnAs | AnnBang | AnnClass | AnnClose -- ^ } or ] or ) or #) etc | AnnComma | AnnDarrow | AnnData | AnnDcolon .... ``` == Capturing in the lexer/parser == The annotations are captured in the lexer / parser by extending PState to include a field In `parser/Lexer.x` ```lang=haskell data PState = PState { .... annotations :: [(ApiAnnKey,SrcSpan)] -- Annotations giving the locations of 'noise' tokens in the -- source, so that users of the GHC API can do source to -- source conversions. } ``` The lexer exposes a helper function to add an annotation ```lang=haskell addAnnotation :: SrcSpan -> Ann -> SrcSpan -> P () addAnnotation l a v = P $ \s -> POk s { annotations = ((AK l a), v) : annotations s } () ``` The parser also has some helper functions of the form ```lang=haskell type MaybeAnn = Maybe (SrcSpan -> P ()) gl = getLoc gj x = Just (gl x) ams :: Located a -> [MaybeAnn] -> P (Located a) ams a@(L l _) bs = (mapM_ (\a -> a l) $ catMaybes bs) >> return a ``` This allows annotations to be captured in the parser by means of ``` ctypedoc :: { LHsType RdrName } : 'forall' tv_bndrs '.' ctypedoc {% hintExplicitForall (getLoc $1) >> ams (LL $ mkExplicitHsForAllTy $2 (noLoc []) $4) [mj AnnForall $1,mj AnnDot $3] } | context '=>' ctypedoc {% ams (LL $ mkQualifiedHsForAllTy $1 $3) [mj AnnDarrow $2] } | ipvar '::' type {% ams (LL (HsIParamTy (unLoc $1) $3)) [mj AnnDcolon $2] } | typedoc { $1 } ``` == Parse result == ```lang-haskell data HsParsedModule = HsParsedModule { hpm_module :: Located (HsModule RdrName), hpm_src_files :: [FilePath], -- ^ extra source files (e.g. from #includes). The lexer collects -- these from '# ' pragmas, which the C preprocessor -- leaves behind. These files and their timestamps are stored in -- the .hi file, so that we can force recompilation if any of -- them change (#3589) hpm_annotations :: ApiAnns } -- | The result of successful parsing. data ParsedModule = ParsedModule { pm_mod_summary :: ModSummary , pm_parsed_source :: ParsedSource , pm_extra_src_files :: [FilePath] , pm_annotations :: ApiAnns } ``` This diff depends on D426 Test Plan: sh ./validate Reviewers: austin, simonpj, Mikolaj Reviewed By: simonpj, Mikolaj Subscribers: Mikolaj, goldfire, thomie, carter Differential Revision: https://phabricator.haskell.org/D438 GHC Trac Issues: #9628 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:25:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:25:48 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.71110f5e5b60e0b7977138cba807827a@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7927658ed1dcf557c7dd78e4b9844100521391c8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7927658ed1dcf557c7dd78e4b9844100521391c8" AST changes to prepare for API annotations, for #9628 Summary: AST changes to prepare for API annotations Add locations to parts of the AST so that API annotations can then be added. The outline of the whole process is captured here https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations This change updates the haddock submodule. Test Plan: sh ./validate Reviewers: austin, simonpj, Mikolaj Reviewed By: simonpj, Mikolaj Subscribers: thomie, goldfire, carter Differential Revision: https://phabricator.haskell.org/D426 GHC Trac Issues: #9628 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:25:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:25:48 -0000 Subject: [GHC] #3589: Recompilation checker doesn't take into account CPP headers In-Reply-To: <047.5d4e10ff362a5a53fb60efa7fea2fd88@haskell.org> References: <047.5d4e10ff362a5a53fb60efa7fea2fd88@haskell.org> Message-ID: <062.54e7ea875f6d05e3c1c226bcef8b6430@haskell.org> #3589: Recompilation checker doesn't take into account CPP headers -------------------------------------+--------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | -------------------------------------+--------------------------------- Comment (by Austin Seipp ): In [changeset:"803fc5db31f084b73713342cdceaed5a9c664267/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="803fc5db31f084b73713342cdceaed5a9c664267" Add API Annotations Summary: The final design and discussion is captured at https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations This is a proof of concept implementation of a completely separate annotation structure, populated in the parser,and tied to the AST by means of a virtual "node-key" comprising the surrounding SrcSpan and a value derived from the specific constructor used for the node. The key parts of the design are the following. == The Annotations == In `hsSyn/ApiAnnotation.hs` ```lang=haskell type ApiAnns = (Map.Map ApiAnnKey SrcSpan, Map.Map SrcSpan [Located Token]) type ApiAnnKey = (SrcSpan,AnnKeywordId) -- --------------------------------------------------------------------- -- | Retrieve an annotation based on the @SrcSpan@ of the annotated AST -- element, and the known type of the annotation. getAnnotation :: ApiAnns -> SrcSpan -> AnnKeywordId -> Maybe SrcSpan getAnnotation (anns,_) span ann = Map.lookup (span,ann) anns -- |Retrieve the comments allocated to the current @SrcSpan@ getAnnotationComments :: ApiAnns -> SrcSpan -> [Located Token] getAnnotationComments (_,anns) span = case Map.lookup span anns of Just cs -> cs Nothing -> [] -- | Note: in general the names of these are taken from the -- corresponding token, unless otherwise noted data AnnKeywordId = AnnAs | AnnBang | AnnClass | AnnClose -- ^ } or ] or ) or #) etc | AnnComma | AnnDarrow | AnnData | AnnDcolon .... ``` == Capturing in the lexer/parser == The annotations are captured in the lexer / parser by extending PState to include a field In `parser/Lexer.x` ```lang=haskell data PState = PState { .... annotations :: [(ApiAnnKey,SrcSpan)] -- Annotations giving the locations of 'noise' tokens in the -- source, so that users of the GHC API can do source to -- source conversions. } ``` The lexer exposes a helper function to add an annotation ```lang=haskell addAnnotation :: SrcSpan -> Ann -> SrcSpan -> P () addAnnotation l a v = P $ \s -> POk s { annotations = ((AK l a), v) : annotations s } () ``` The parser also has some helper functions of the form ```lang=haskell type MaybeAnn = Maybe (SrcSpan -> P ()) gl = getLoc gj x = Just (gl x) ams :: Located a -> [MaybeAnn] -> P (Located a) ams a@(L l _) bs = (mapM_ (\a -> a l) $ catMaybes bs) >> return a ``` This allows annotations to be captured in the parser by means of ``` ctypedoc :: { LHsType RdrName } : 'forall' tv_bndrs '.' ctypedoc {% hintExplicitForall (getLoc $1) >> ams (LL $ mkExplicitHsForAllTy $2 (noLoc []) $4) [mj AnnForall $1,mj AnnDot $3] } | context '=>' ctypedoc {% ams (LL $ mkQualifiedHsForAllTy $1 $3) [mj AnnDarrow $2] } | ipvar '::' type {% ams (LL (HsIParamTy (unLoc $1) $3)) [mj AnnDcolon $2] } | typedoc { $1 } ``` == Parse result == ```lang-haskell data HsParsedModule = HsParsedModule { hpm_module :: Located (HsModule RdrName), hpm_src_files :: [FilePath], -- ^ extra source files (e.g. from #includes). The lexer collects -- these from '# ' pragmas, which the C preprocessor -- leaves behind. These files and their timestamps are stored in -- the .hi file, so that we can force recompilation if any of -- them change (#3589) hpm_annotations :: ApiAnns } -- | The result of successful parsing. data ParsedModule = ParsedModule { pm_mod_summary :: ModSummary , pm_parsed_source :: ParsedSource , pm_extra_src_files :: [FilePath] , pm_annotations :: ApiAnns } ``` This diff depends on D426 Test Plan: sh ./validate Reviewers: austin, simonpj, Mikolaj Reviewed By: simonpj, Mikolaj Subscribers: Mikolaj, goldfire, thomie, carter Differential Revision: https://phabricator.haskell.org/D438 GHC Trac Issues: #9628 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:31:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:31:31 -0000 Subject: [GHC] #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" In-Reply-To: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> References: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> Message-ID: <060.6dcfbf2102b89746d8ef303b15f4316a@haskell.org> #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" -------------------------------------------+---------------------------- Reporter: jfeltz | Owner: leroux Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: T9293 | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D516 | -------------------------------------------+---------------------------- Comment (by Austin Seipp ): In [changeset:"3e4f49b04e6e97256b4d34221e209e1051bf06ae/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3e4f49b04e6e97256b4d34221e209e1051bf06ae" Fixes ghci :unset -X so that it doesn't fail to reverse option. (fixes trac #9293) Summary: ghci unset could not reverse language extensions. Reviewers: hvr, thomie, austin Reviewed By: hvr, thomie, austin Subscribers: goldfire, hvr, thomie, carter Differential Revision: https://phabricator.haskell.org/D516 GHC Trac Issues: #9293 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:34:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:34:05 -0000 Subject: [GHC] #2431: Allow empty case analysis In-Reply-To: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@haskell.org> References: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@haskell.org> Message-ID: <063.7ce62fa7ffcdfc6856b6332bcdf03788@haskell.org> #2431: Allow empty case analysis -------------------------------------+------------------------------------- Reporter: RalfHinze | Owner: Type: feature request | Status: closed Priority: low | Milestone: ? Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: empty case Operating System: Unknown/Multiple | analysis Type of failure: None/Unknown | Architecture: Unknown/Multiple Test Case: | Difficulty: Unknown deSugar/should_compile/T2431 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a97f90cecb6351a6db5a62c1551fcbf079b0acdd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a97f90cecb6351a6db5a62c1551fcbf079b0acdd" Add Data.Void to base (re #9814) This adds the module `Data.Void` (formerly provided by Edward Kmett's `void` package) to `base`. The original Haskell98 compatible implementation has been modified to use modern GHC features (among others this makes use of `EmptyCase` as motivated by #2431), and `vacuousM` was dropped since it's redundant now with the AMP in place. Instances for classes not part of `base` had to be dropped as well. TODO: Documentation could be improved Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D506 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:34:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:34:05 -0000 Subject: [GHC] #9814: Add Data.Void to base In-Reply-To: <046.50c1f1ca69dc11e2d1b5288936528b83@haskell.org> References: <046.50c1f1ca69dc11e2d1b5288936528b83@haskell.org> Message-ID: <061.3f5d3c5698534e9353d41fb620da52fd@haskell.org> #9814: Add Data.Void to base -------------------------------------+------------------------------------- Reporter: shachaf | Owner: hvr Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D506 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a97f90cecb6351a6db5a62c1551fcbf079b0acdd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a97f90cecb6351a6db5a62c1551fcbf079b0acdd" Add Data.Void to base (re #9814) This adds the module `Data.Void` (formerly provided by Edward Kmett's `void` package) to `base`. The original Haskell98 compatible implementation has been modified to use modern GHC features (among others this makes use of `EmptyCase` as motivated by #2431), and `vacuousM` was dropped since it's redundant now with the AMP in place. Instances for classes not part of `base` had to be dropped as well. TODO: Documentation could be improved Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D506 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 17:35:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 17:35:12 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.a8536f51fd88cc38b5f730ce6a29c785@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Nice find Yuras. Should be easy to put that check back in then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 18:16:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 18:16:42 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.17e329a90339dc120b70205cfebf4537@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: Phab:D504 | -------------------------------------+------------------------------------- Comment (by dredozubov): jstolarek, I definitely meant "the latest SSE version". I'll try to look into writing tests for this patch tonight, sadly this week've been really busy and i was unable to work on something else except my day work. > all msse flags are listed by --show-options flag > incorrect -msse flag is rejected (see ?https://phabricator.haskell.org/D503 for an example how to do that). This test case seems a little off to me. It tests OptKind + --show-options behaviour(which currently works), not patch in question. Maybe it'll be a little better to test that right flag(the latest sse version) would be set, if user provides two or more. carter, afaik for each pair of versions of sse older one will contain subset of instructions from newer. I'm not really an expert on this matter though, so If someone else can verify that - it would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 18:25:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 18:25:32 -0000 Subject: [GHC] #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" In-Reply-To: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> References: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> Message-ID: <060.90bee67e2100ca6dc63e303906f715f5@haskell.org> #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" ---------------------------------------------+---------------------------- Reporter: jfeltz | Owner: leroux Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghci/scripts/T9293 | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D516 | ---------------------------------------------+---------------------------- Changes (by thomie): * status: patch => closed * testcase: T9293 => ghci/scripts/T9293 * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 19:16:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 19:16:13 -0000 Subject: [GHC] #7484: Template Haskell allows building invalid record fields/names In-Reply-To: <045.397b38fee58f310a634c2d78baa84281@haskell.org> References: <045.397b38fee58f310a634c2d78baa84281@haskell.org> Message-ID: <060.1ec131409072a9534918169fb55df0e4@haskell.org> #7484: Template Haskell allows building invalid record fields/names -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.6.1 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8750 None/Unknown | Test Case: th/T7484 | Blocking: | Differential Revisions: Phab:D431 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * testcase: => th/T7484 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 19:17:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 19:17:34 -0000 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> Message-ID: <059.68fc2bab2f0e1fc31b9a77b467e922b9@haskell.org> #1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T1476 | th/T1476b | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * testcase: => th/T1476 th/T1476b * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 19:18:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 19:18:26 -0000 Subject: [GHC] #9824: Pattern quotations warn about unused matches In-Reply-To: <047.5d2a5cd8668339c26227f5e3e81864a7@haskell.org> References: <047.5d2a5cd8668339c26227f5e3e81864a7@haskell.org> Message-ID: <062.547e5d847ea4395e86d389a29a1f9dec@haskell.org> #9824: Pattern quotations warn about unused matches -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T9824 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => th/T9824 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 19:19:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 19:19:45 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.acc53649026f603a2cb50267690b11aa@haskell.org> #9176: GHC not generating dyn_hi files -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by heatsink): Replying to [comment:9 thomie]: Thanks for reproducing this bug. That looks like what I experienced, except for the package not installing with HEAD. The "Bad interface file" message looks like it's refusing to install a package with inconsistent ABI hashes, which may be an improvement. I don't think anyone has worked out what properties are intended to hold for interface files, such as whether having mismatched ABI hashes is allowed. I brought this up on the mailing and got replies about a few use cases that should be supported. I's not clear to me what this means for the implementation. https://www.haskell.org/pipermail/ghc-devs/2014-June/005301.html https://www.haskell.org/pipermail/ghc-devs/2014-July/005475.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 19:24:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 19:24:42 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.083d4190db3303fa564bf3391bfff38a@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"c0ad5bc03e02ce0d7d545599e4b1a68a6f727f2b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c0ad5bc03e02ce0d7d545599e4b1a68a6f727f2b" Capture original source for literals Summary: Make HsLit and OverLitVal have original source strings, for source to source conversions using the GHC API This is part of the ongoing AST Annotations work, as captured in https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations and https://ghc.haskell.org/trac/ghc/ticket/9628#comment:28 The motivations for the literals is as follows ```lang=haskell x,y :: Int x = 0003 y = 0x04 s :: String s = "\x20" c :: Char c = '\x20' d :: Double d = 0.00 blah = x where charH = '\x41'# intH = 0004# wordH = 005## floatH = 3.20# doubleH = 04.16## x = 1 ``` Test Plan: ./sh validate Reviewers: simonpj, austin Reviewed By: simonpj, austin Subscribers: thomie, goldfire, carter, simonmar Differential Revision: https://phabricator.haskell.org/D412 GHC Trac Issues: #9628 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 20:19:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 20:19:40 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.8d7a489cea6d5fbb875ff2d5f577dc38@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 20:32:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 20:32:34 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.80777eec5de7e967eae444a0939dd87d@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D518| -------------------------------------+------------------------------------- Changes (by GregWeber): * status: new => patch * differential: => https://phabricator.haskell.org/D518 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 21:03:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 21:03:20 -0000 Subject: [GHC] #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS Message-ID: <047.e4f44909e905adacb4005302519ba187@haskell.org> #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS ----------------------------+--------------------------------------------- Reporter: jzellner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+--------------------------------------------- Hey there, I'm having trouble building vimus (https://github.com/vimus/vimus) on NixOS. The package builds fine locally for an x64 system, but is failing on i686 builds. On the NixOS builder: http://hydra.nixos.org/build/17512103/nixlog/2 {{{ [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ ./Setup clean && ./Setup configure --enable-shared --enable-library-vanilla --enable-executable- dynamic --enable-tests --ghc- option=-optl=-Wl,-rpath=/nix/store/cgkfxxk1iz30fg0r3kf9dv2p550i5hn2-vimus-0.2.0/lib/ghc-7.8.3/vimus-0.2.0 --ghc-option=-j8 && ./Setup build cleaning... Configuring vimus-0.2.0... Building vimus-0.2.0... Preprocessing library vimus-0.2.0... [ 1 of 39] Compiling Constant ( dist/build/Constant.hs, dist/build/Constant.o ) [ 2 of 39] Compiling CursesUtil ( ncursesw/src/CursesUtil.hs, dist/build/CursesUtil.o ) [ 3 of 39] Compiling Timer ( src/Timer.hs, dist/build/Timer.o ) [ 4 of 39] Compiling UI.Curses.Type ( dist/build/UI/Curses/Type.hs, dist/build/UI/Curses/Type.o ) [ 5 of 39] Compiling Misc ( dist/build/Misc.hs, dist/build/Misc.o ) ncursesw/src/Misc.chs:7:1: Warning: The import of ?Foreign.C.String? is redundant except perhaps to import instances from ?Foreign.C.String? To import instances alone, use: import Foreign.C.String() ncursesw/src/Misc.chs:8:1: Warning: The import of ?Foreign.Marshal.Alloc? is redundant except perhaps to import instances from ?Foreign.Marshal.Alloc? To import instances alone, use: import Foreign.Marshal.Alloc() ncursesw/src/Misc.chs:9:1: Warning: The import of ?Foreign.Storable? is redundant except perhaps to import instances from ?Foreign.Storable? To import instances alone, use: import Foreign.Storable() ncursesw/src/Misc.chs:10:1: Warning: The import of ?Foreign.ForeignPtr? is redundant except perhaps to import instances from ?Foreign.ForeignPtr? To import instances alone, use: import Foreign.ForeignPtr() ncursesw/src/Misc.chs:12:1: Warning: The import of ?Data.Char? is redundant except perhaps to import instances from ?Data.Char? To import instances alone, use: import Data.Char() ncursesw/src/Misc.chs:29:1: Warning: Top-level binding with no type signature: cFromBool :: Bool -> Integer ncursesw/src/Misc.chs:29:13: Warning: Defaulting the following constraint(s) to type ?Integer? (Num a0) arising from a use of ?fromBool? In the expression: fromBool In an equation for ?cFromBool?: cFromBool = fromBool ncursesw/src/Misc.chs:30:1: Warning: Top-level binding with no type signature: cToBool :: Integer -> Bool ncursesw/src/Misc.chs:30:13: Warning: Defaulting the following constraint(s) to type ?Integer? (Num a0) arising from a use of ?toBool? at ncursesw/src/Misc.chs:30:13-18 (Eq a0) arising from a use of ?toBool? at ncursesw/src/Misc.chs:30:13-18 In the expression: toBool In an equation for ?cToBool?: cToBool = toBool ncursesw/src/Misc.chs:42:1: Warning: Top-level binding with no type signature: fromAttr :: Attr -> CInt ncursesw/src/Misc.chs:77:1: Warning: Top-level binding with no type signature: wcolor_set :: Window -> Int -> IO Status ncursesw/src/Misc.chs:86:1: Warning: Top-level binding with no type signature: wattr_off :: Window -> [Attribute] -> IO Status ncursesw/src/Misc.chs:90:1: Warning: Top-level binding with no type signature: wattr_on :: Window -> [Attribute] -> IO Status ncursesw/src/Misc.chs:98:1: Warning: Top-level binding with no type signature: wchgat :: Window -> Int -> [Attribute] -> Int -> IO Status ncursesw/src/Misc.chs:103:1: Warning: Top-level binding with no type signature: mvwchgat :: Window -> Int -> Int -> Int -> [Attribute] -> Int -> IO Status [ 6 of 39] Compiling CursesInput ( dist/build/CursesInput.hs, dist/build/CursesInput.o ) [ 7 of 39] Compiling Instances ( src/Instances.hs, dist/build/Instances.o ) [ 8 of 39] Compiling Data.List.Pointed ( src/Data/List/Pointed.hs, dist/build/Data/List/Pointed.o ) [ 9 of 39] Compiling Data.List.Zipper ( src/Data/List/Zipper.hs, dist/build/Data/List/Zipper.o ) [10 of 39] Compiling UI.Curses.Key ( dist/build/UI/Curses/Key.hs, dist/build/UI/Curses/Key.o ) [11 of 39] Compiling Vimus.Tab ( src/Vimus/Tab.hs, dist/build/Vimus/Tab.o ) [12 of 39] Compiling Vimus.Command.Parser ( src/Vimus/Command/Parser.hs, dist/build/Vimus/Command/Parser.o ) [13 of 39] Compiling Vimus.Key ( src/Vimus/Key.hs, dist/build/Vimus/Key.o ) [14 of 39] Compiling Paths_vimus ( dist/build/autogen/Paths_vimus.hs, dist/build/Paths_vimus.o ) [15 of 39] Compiling Vimus.Song ( src/Vimus/Song.hs, dist/build/Vimus/Song.o ) [16 of 39] Compiling Vimus.Song.Format ( src/Vimus/Song/Format.hs, dist/build/Vimus/Song/Format.o ) [17 of 39] Compiling Vimus.Queue ( src/Vimus/Queue.hs, dist/build/Vimus/Queue.o ) [18 of 39] Compiling Vimus.Util ( src/Vimus/Util.hs, dist/build/Vimus/Util.o ) [19 of 39] Compiling Option ( src/Option.hs, dist/build/Option.o ) [20 of 39] Compiling PlaybackState ( src/PlaybackState.hs, dist/build/PlaybackState.o ) [21 of 39] Compiling Curses ( dist/build/Curses.hs, dist/build/Curses.o ) ncursesw/src/Curses.chs:73:1: Warning: The import of ?Foreign.C.String? is redundant except perhaps to import instances from ?Foreign.C.String? To import instances alone, use: import Foreign.C.String() ncursesw/src/Curses.chs:76:1: Warning: The import of ?chr? from module ?Data.Char? is redundant ncursesw/src/Curses.chs:150:1: Warning: Defined but not used: ?wnoutrefresh? ncursesw/src/Curses.chs:151:1: Warning: Defined but not used: ?doupdate? ncursesw/src/Curses.chs:152:1: Warning: Defined but not used: ?redrawwin? ncursesw/src/Curses.chs:153:1: Warning: Defined but not used: ?wredrawln? ncursesw/src/Curses.chs:160:1: Warning: Defined but not used: ?getparyx? ncursesw/src/Curses.chs:207:1: Warning: Defined but not used: ?cFromBool? ncursesw/src/Curses.chs:207:1: Warning: Top-level binding with no type signature: cFromBool :: Bool -> Integer ncursesw/src/Curses.chs:207:13: Warning: Defaulting the following constraint(s) to type ?Integer? (Num a0) arising from a use of ?fromBool? In the expression: fromBool In an equation for ?cFromBool?: cFromBool = fromBool ncursesw/src/Curses.chs:374:1: Warning: Defined but not used: ?wnoutrefresh'_? ncursesw/src/Curses.chs:377:1: Warning: Defined but not used: ?doupdate'_? ncursesw/src/Curses.chs:380:1: Warning: Defined but not used: ?redrawwin'_? ncursesw/src/Curses.chs:383:1: Warning: Defined but not used: ?wredrawln'_? ncursesw/src/Curses.chs:389:1: Warning: Defined but not used: ?getparyx'_? [22 of 39] Compiling UI.Curses ( ncursesw/src/UI/Curses.hs, dist/build/UI/Curses.o ) [23 of 39] Compiling Vimus.WindowLayout ( src/Vimus/WindowLayout.hs, dist/build/Vimus/WindowLayout.o ) [24 of 39] Compiling Vimus.Widget.Type ( src/Vimus/Widget/Type.hs, dist/build/Vimus/Widget/Type.o ) [25 of 39] Compiling Content ( src/Content.hs, dist/build/Content.o ) [26 of 39] Compiling Vimus.Input ( src/Vimus/Input.hs, dist/build/Vimus/Input.o ) [27 of 39] Compiling Vimus.Macro ( src/Vimus/Macro.hs, dist/build/Vimus/Macro.o ) [28 of 39] Compiling Vimus.Render ( src/Vimus/Render.hs, dist/build/Vimus/Render.o ) [29 of 39] Compiling Vimus.Ruler ( src/Vimus/Ruler.hs, dist/build/Vimus/Ruler.o ) [30 of 39] Compiling Vimus.Type ( src/Vimus/Type.hs, dist/build/Vimus/Type.o ) [31 of 39] Compiling Vimus.Command.Type ( src/Vimus/Command/Type.hs, dist/build/Vimus/Command/Type.o ) [32 of 39] Compiling Vimus.Command.Help ( src/Vimus/Command/Help.hs, dist/build/Vimus/Command/Help.o ) [33 of 39] Compiling Vimus.Command.Completion ( src/Vimus/Command/Completion.hs, dist/build/Vimus/Command/Completion.o ) [34 of 39] Compiling Vimus.Command.Core ( src/Vimus/Command/Core.hs, dist/build/Vimus/Command/Core.o ) [35 of 39] Compiling Vimus.Widget.ListWidget ( src/Vimus/Widget/ListWidget.hs, dist/build/Vimus/Widget/ListWidget.o ) [36 of 39] Compiling Vimus.Widget.TextWidget ( src/Vimus/Widget/TextWidget.hs, dist/build/Vimus/Widget/TextWidget.o ) [37 of 39] Compiling Vimus.Widget.HelpWidget ( src/Vimus/Widget/HelpWidget.hs, dist/build/Vimus/Widget/HelpWidget.o ) [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package text-1.2.0.0 ... linking ... done. Loading package hashable-1.2.2.0 ... linking ... done. Loading package scientific-0.3.3.2 ... linking ... done. Loading package attoparsec-0.12.1.2 ... linking ... done. Loading package setlocale-1.0.0.1 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package wcwidth-0.0.2 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package data-default-class-0.0.1 ... linking ... done. Loading package data-default-instances-base-0.0.1 ... linking ... done. Loading package data-default-instances-containers-0.0.1 ... linking ... done. Loading package dlist-0.7.1 ... linking ... done. Loading package data-default-instances-dlist-0.0.1 ... linking ... done. Loading package data-default-instances-old-locale-0.0.1 ... linking ... done. Loading package data-default-0.5.3 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package network-2.6.0.2 ... linking ... done. Loading package libmpd-0.9.0.1 ... linking ... done. : ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-linux): Loading temp shared object failed: /tmp/ghc6364_1/ghc6364_192.so: undefined symbol: nm_getyx Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ nixos-version 14.11pre52840.c347f1c (Caterpillar) [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ uname -a Linux ip-10-83-15-102.us-west-2.compute.internal 3.12.30 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux }}} Thanks for any help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 21:31:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 21:31:51 -0000 Subject: [GHC] #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.abdb99d213b0ebdd34617384012b5025@haskell.org> #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4213 | Differential Revisions: Phab:D155 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"e16a342d70b92fc8480793d3ec911853f0c31e44/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e16a342d70b92fc8480793d3ec911853f0c31e44" llvmGen: Compatibility with LLVM 3.5 (re #9142) Due to changes in LLVM 3.5 aliases now may only refer to definitions. Previously to handle symbols defined outside of the current commpilation unit GHC would emit both an `external` declaration, as well as an alias pointing to it, e.g., @stg_BCO_info = external global i8 @stg_BCO_info$alias = alias private i8* @stg_BCO_info Where references to `stg_BCO_info` will use the alias `stg_BCO_info$alias`. This is not permitted under the new alias behavior, resulting in errors resembling, Alias must point to a definition i8* @"stg_BCO_info$alias" To fix this, we invert the naming relationship between aliases and definitions. That is, now the symbol definition takes the name `@stg_BCO_info$def` and references use the actual name, `@stg_BCO_info`. This means the external symbols can be handled by simply emitting an `external` declaration, @stg_BCO_info = external global i8 Whereas in the case of a forward declaration we emit, @stg_BCO_info = alias private i8* @stg_BCO_info$def Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D155 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 21:38:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 21:38:36 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.0b318e1069b43a8f28cf8e29c1b1c8c1@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged in fec1c3091b43f316ae7e683ed72b3ec175d9fd6e -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 22:30:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 22:30:50 -0000 Subject: [GHC] #9822: Add displayException to Exception typeclass In-Reply-To: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> References: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> Message-ID: <062.58d0ada9514f886dc649d6fd21181a66@haskell.org> #9822: Add displayException to Exception typeclass -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D517 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"3222b7ae347be092bdd414f7b43bee18861b0e1e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3222b7ae347be092bdd414f7b43bee18861b0e1e" Add displayException method to Exception (#9822) Defaults to using `show` to prevent any breakage of existing code. Also provide a custom implementation for `SomeException` which uses the underlying exception's `displayException`. Differential Revision: https://phabricator.haskell.org/D517 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 22:45:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 22:45:13 -0000 Subject: [GHC] #9816: Add function for size-checked conversion of Integral types In-Reply-To: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> References: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> Message-ID: <057.fa0c366fe69da464938d7c1670d734b3@haskell.org> #9816: Add function for size-checked conversion of Integral types -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: D512 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"02f8f6ad7bd3d792459a1d33e8d0d57dcf1ea424/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="02f8f6ad7bd3d792459a1d33e8d0d57dcf1ea424" Add function for size-checked conversion of Integral types The new function `Data.Bits.toIntegralSized` provides a similar functionality to `fromIntegral` but adds validation that the argument fits in the result type's size. The implementation of `toIntegralSized` has been derived from `intCastMaybe` (which is part of Herbert Valerio Riedel's `int-cast` package, see http://hackage.haskell.org/package/int-cast) Addresses #9816 Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D512 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 23:04:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 23:04:59 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.555c6436ab4745097d58311973c1637a@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D337 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"624a7c5a2eee0c0ba486a45550680052c2c79849/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="624a7c5a2eee0c0ba486a45550680052c2c79849" ghc: allow --show-options and --interactive together Summary: Previously 'ghc --show-options' showed all options that GHC can possibly accept. With this patch, it'll only show the options that have effect in non-interactive modes. This change also adds support for using 'ghc --interactive --show-options' which previously was disallowed. This command will show all options that have effect in the interactive mode. The CmdLineParser is updated to know about the GHC modes, and then each flag is annotated with which mode it has effect. This fixes #9259. Test Plan: Try out --show-options with --interactive on the command line. With and without --interactive should give different results. Run the test suite, mode001 has been updated to verify this new flag combination. Reviewers: austin, jstolarek Reviewed By: austin, jstolarek Subscribers: jstolarek, thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D337 GHC Trac Issues: #9259 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 23:04:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 23:04:59 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.4c871380ec2be59e183372eeae48dfcd@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D442 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"2cc854b7133e38c7ad1107057931761782d03594/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2cc854b7133e38c7ad1107057931761782d03594" Add -fdefer-typed-holes flag which defers hole errors to runtime. Summary: As proposed by Richard on Trac. This patch adds a new flag -fdefer-typed- holes and changes the semantics of the -fno-warn-typed-holes flag. To summarise, by default GHC has typed holes enabled and produces a compile error when it encounters a typed hole. When -fdefer-type-errors OR -fdefer-typed-holes is enabled, hole errors are converted to warnings and result in runtime errors when evaluated. The warning flag -fwarn-typed-holes is on by default. Without -fdefer- type-errors or -fdefer-typed-holes this flag is a no-op, since typed holes are an error under these conditions. If either of the defer flags are enabled (converting typed hole errors into warnings) the -fno-warn-typed-holes flag disables the warnings. This means compilation silently succeeds and evaluating a hole will produce a runtime error. The rationale behind allowing typed holes warnings to be silenced is that tools like Syntastic for vim highlight warnings and hole warnings may be undesirable. Signed-off-by: Merijn Verstraaten Test Plan: validate Reviewers: austin, simonpj, thomie Reviewed By: simonpj, thomie Subscribers: Fuuzetsu, thomie, carter Differential Revision: https://phabricator.haskell.org/D442 GHC Trac Issues: #9497 Conflicts: compiler/main/DynFlags.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 21 23:10:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Nov 2014 23:10:16 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.7dfd1edce2b9aa5f09a688edb8ab006d@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: duncan Type: bug | Status: patch Priority: normal | Milestone: ? Component: Core | Version: 6.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D395 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"137b33133f49a994e5d147c5b30a8fcfc610eada/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="137b33133f49a994e5d147c5b30a8fcfc610eada" Deprecate Data.Version.versionTags (#2496) The library submission was accepted: http://www.haskell.org/pipermail/libraries/2014-September/023777.html The T5892ab testcases were changed to use `Data.Tree` instead of `Data.Version` Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:09:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:09:48 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.4be125f8773d6742ec31c69b19e1775c@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"8a8cdbbfd855015049526c7945cbe9ccbb152f1e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8a8cdbbfd855015049526c7945cbe9ccbb152f1e" Implement `Natural` number type (re #9818) This implements a `Natural` type for representing unsigned arbitrary precision integers. When available, `integer-gmp>=1.0.0`'s `BigNat` type is used as building-block to construct `Natural` as an algebraic data-type. Otherwise, `Natural` falls back being a `newtype`-wrapper around `Integer` (as is done in Edward Kmett's `nats` package). The `GHC.Natural` module exposes an internal GHC-specific API, while `Numeric.Natural` provides the official & portable API. Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D473 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:40:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:40:28 -0000 Subject: [GHC] #8572: Building an empty module with profiling requires profiling libraries for integer-gmp In-Reply-To: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> References: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> Message-ID: <059.ee5b504131520caeba0e648071aa1ef3@haskell.org> #8572: Building an empty module with profiling requires profiling libraries for integer-gmp -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: hvr (added) * status: patch => infoneeded * component: Compiler (Type checker) => Compiler * milestone: => 7.12.1 Comment: I don't really know if I like this patch. It seems very fragile and most of the code has been refactored now. I think Herbert should take a look, but I hope he'd agree. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:41:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:41:50 -0000 Subject: [GHC] #8460: Annotation reification with types in TH In-Reply-To: <044.054b1a18fb230f3acdfda8b8bca50885@haskell.org> References: <044.054b1a18fb230f3acdfda8b8bca50885@haskell.org> Message-ID: <059.283e42103f5f1d60b1fc1c052166005e@haskell.org> #8460: Annotation reification with types in TH -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: feature | Status: infoneeded request | Milestone: 7.12.1 Priority: normal | Version: 7.7 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8397 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded * milestone: 7.10.1 => 7.12.1 Comment: Gergley, sorry for dropping this patch on the floor. As you can tell since last year a lot has changed! Can you please rebase these patches? I also vaguely remember you wrote a wiki page about what they all addressed. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:42:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:42:04 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode In-Reply-To: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> References: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> Message-ID: <059.86cf1f28f92693cc53b75f083bf01d36@haskell.org> #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Other | Blocked By: Test Case: | Related Tickets: #7867 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded * milestone: 7.10.1 => 7.12.1 Comment: Gergley, sorry for dropping this patch on the floor. As you can tell since last year a lot has changed! Can you please rebase these patches? I also vaguely remember you wrote a wiki page about what they all addressed. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:44:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:44:48 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.4e1a620a1b6b5851f452ab71516b2dc9@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded * milestone: => 7.10.1 Comment: Niklas, can you please rebase this patch? I manually did it, but then the test started failing (the `.stdout` file had "compilation IS NOT required" once too many times). Can you please take this and verify it should work? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:45:32 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.da8d19220d84d5e3cb24a1859b6aa686@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thoughtpolice): Here's a WIP patch: https://github.com/ghc/ghc/commit/a3bf4bfae694572b0bf886fcb1191d066d242aed on `wip/8144` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:46:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:46:05 -0000 Subject: [GHC] #9814: Add Data.Void to base In-Reply-To: <046.50c1f1ca69dc11e2d1b5288936528b83@haskell.org> References: <046.50c1f1ca69dc11e2d1b5288936528b83@haskell.org> Message-ID: <061.54e81033023546a8c8a39a9ded819077@haskell.org> #9814: Add Data.Void to base -------------------------------------+------------------------------------- Reporter: shachaf | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D506 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:46:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:46:41 -0000 Subject: [GHC] #9816: Add function for size-checked conversion of Integral types In-Reply-To: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> References: <042.bfe88996b11d2ce4d8286d6ddf8655c3@haskell.org> Message-ID: <057.06693023850b9f16b4119854e74cfebb@haskell.org> #9816: Add function for size-checked conversion of Integral types -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: D512 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:47:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:47:25 -0000 Subject: [GHC] #9822: Add displayException to Exception typeclass In-Reply-To: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> References: <047.5c6c799f4bda0348b755b9cff53f1e44@haskell.org> Message-ID: <062.7a4fc0cf3683c72288798fea8c050c13@haskell.org> #9822: Add displayException to Exception typeclass -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D517 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:48:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:48:42 -0000 Subject: [GHC] #9540: words is not a good producer; unwords is not a good consumer In-Reply-To: <045.cf07c524c3885055d6c8e1249648041f@haskell.org> References: <045.cf07c524c3885055d6c8e1249648041f@haskell.org> Message-ID: <060.0d62d06d28c962f618f73abaf3c180b1@haskell.org> #9540: words is not a good producer; unwords is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: fusion Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D375 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: This was merged: https://phabricator.haskell.org/rGHCe73ab5412935392c03ce736ebee2b1282932c2ff (or just e73ab5412935392c03ce736ebee2b1282932c2ff) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 00:50:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 00:50:54 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.a243fb036dedd39ed522f400db4cfe31@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: 6.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D395 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: duncan => * status: patch => new * milestone: ? => 7.12.1 Comment: Since the patch from Thomas was merged, I'm moving this to 7.12 so we can close it then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 01:32:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 01:32:19 -0000 Subject: [GHC] #9826: add Storable Complex and Ratio instance to base library Message-ID: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> #9826: add Storable Complex and Ratio instance to base library -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- per the libraries discussion + core libraries committee OK, I'm putting a phab differential up for adding Storable instances for Complex and Ratio (and then noticing that theres basically NO tests for Storable except indirectly) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 01:44:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 01:44:44 -0000 Subject: [GHC] #8056: Make Install fails on HEAD In-Reply-To: <048.8cd3de99691cf755991cd01be2e0cfaa@haskell.org> References: <048.8cd3de99691cf755991cd01be2e0cfaa@haskell.org> Message-ID: <063.5350f6bfceeb4acda90a5b7063fcb63e@haskell.org> #8056: Make Install fails on HEAD -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: `make install` should be working now. Please re-open if you find otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 01:51:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 01:51:54 -0000 Subject: [GHC] #9826: add Storable Complex and Ratio instance to base library In-Reply-To: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> References: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> Message-ID: <060.6996525090d22a2b11bc921906d099b3@haskell.org> #9826: add Storable Complex and Ratio instance to base library -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D519 | -------------------------------------+------------------------------------- Changes (by carter): * status: new => patch * differential: => Phab:D519 Comment: still need to add tests... but storable per se has no tests in base! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 02:11:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 02:11:52 -0000 Subject: [GHC] #8057: Warn when supplying version number to package-qualified import (was: PackageImports with versions for ghci) In-Reply-To: <046.dcdda60f854692c73464ccaeed842287@haskell.org> References: <046.dcdda60f854692c73464ccaeed842287@haskell.org> Message-ID: <061.17688ad6e70750e670a145c3df8675c8@haskell.org> #8057: Warn when supplying version number to package-qualified import -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: GHCi => Compiler Old description: > Imports with explicit package names and versions would be nice to have in > GHCi, > because you cannot use the -package and -hide-package options from within > GHCi. > This is what currently happens: > {{{ > $ ghci-7.6.3 -XPackageImports > 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> import Control.Monad.Trans.List > > : > Ambiguous module name `Control.Monad.Trans.List': > it was found in multiple packages: transformers-0.3.0.0 List-0.5.1 > Prelude> import "transformers-0.3.0.0" Control.Monad.Trans.List > > : > Could not find module `Control.Monad.Trans.List' > It is not a module in the current program, or in any known package. > Prelude> :q > Leaving GHCi. > $ ghci-7.6.3 -hide-package List > 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> import Control.Monad.Trans.List > Prelude Control.Monad.Trans.List> > }}} > > However, I now see that the import with explicit package name works, if I > omit the package version. > I think GHCi should at least warn that providing a version does not work. > > See also #2362 New description: {{{ $ ghci -XPackageImports GHCi, version 7.8.3: ... Prelude> import "transformers-0.3.0.0" Control.Monad.Trans.List : Could not find module ?Control.Monad.Trans.List? It is not a module in the current program, or in any known package. Prelude> import "transformers" Control.Monad.Trans.List Prelude Control.Monad.Trans.List> }}} The import with explicit package name works, if I omit the package version. I think GHC should at least warn that providing a version does not work. See also #2362. -- Comment: Changed the description, because it's not a GHCi only problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 02:17:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 02:17:43 -0000 Subject: [GHC] #8054: Undefined symbol during linking In-Reply-To: <043.c28c808c0c2f8a0b7f35e4c913ea79bf@haskell.org> References: <043.c28c808c0c2f8a0b7f35e4c913ea79bf@haskell.org> Message-ID: <058.1b02254ec4c52a831f954097e1e6ed18@haskell.org> #8054: Undefined symbol during linking ---------------------------------------+---------------------------------- Reporter: case | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: There were a lot of linking problem on Mac OSX with GHC 7.6. The situation should be much improved with GHC 7.8.3. Please re-open if you're still having problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 02:30:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 02:30:45 -0000 Subject: [GHC] #8046: Make the timer management scale better across multicore In-Reply-To: <044.ea1ecebf53098ec25fe7d05d3e1cffff@haskell.org> References: <044.ea1ecebf53098ec25fe7d05d3e1cffff@haskell.org> Message-ID: <059.60c3fd016d2abfe0b451a97019de38d4@haskell.org> #8046: Make the timer management scale better across multicore -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #7653 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug * type: bug => feature request * related: => #7653 Old description: > A recent commit > > {{{ > commit e843e73690f828498f6e33bb89f47a50c3ab2ac9 > Author: Ian Lynagh > Date: Sat Jun 8 20:19:59 2013 +0100 > > IO manager: Edit the timeout queue directly, rather than using an > edit list > > Fixes #7653. > }}} > > undid an optimization to the management of timeouts (to fix a bug, which > is good). We should check how much this hurt performance, but it might be > better to rewrite the timeout management altogether. The current scheme > scales poorly to several cores. We should probably have one priority > queue per core and use an efficient mutable data structure. New description: Commit 2d5eccdf1cfb389074cc2e5b52ae40b535c3b235 {{{ Author: Ian Lynagh Date: Sat Jun 8 20:19:59 2013 +0100 IO manager: Edit the timeout queue directly, rather than using an edit list Fixes #7653. }}} undid an optimization to the management of timeouts (to fix a bug, which is good). We should check how much this hurt performance, but it might be better to rewrite the timeout management altogether. The current scheme scales poorly to several cores. We should probably have one priority queue per core and use an efficient mutable data structure. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 02:37:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 02:37:33 -0000 Subject: [GHC] #8044: "Inaccessible code" error reported in wrong place In-Reply-To: <047.ca5edea8fc93ab55042ca6cee2bd6cb8@haskell.org> References: <047.ca5edea8fc93ab55042ca6cee2bd6cb8@haskell.org> Message-ID: <062.5ed69102133f9764c57b9086938d1579@haskell.org> #8044: "Inaccessible code" error reported in wrong place -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 (Type checker) | Keywords: GADTs Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.10.1 Comment: This seems to be fixed. A regression test should probably be added. HEAD now shows an error message about the second clause of `frob`, no longer about the first clause. {{{ $ ghc-7.9.20141121 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:16:13: Couldn't match type ?Frob a? with ?Char? Expected type: X (Frob a) Actual type: X Char Relevant bindings include frob :: X a -> X (Frob a) (bound at Bug.hs:15:1) In the expression: XChar In an equation for ?frob?: frob _ = XChar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 02:42:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 02:42:48 -0000 Subject: [GHC] #8043: Feature Request : Qualified module exports In-Reply-To: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> References: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> Message-ID: <059.90d120f5f12fcea2ba36af8ed3ad88db@haskell.org> #8043: Feature Request : Qualified module exports -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 03:13:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 03:13:43 -0000 Subject: [GHC] #8036: Demand analyser is unpacking too deeply In-Reply-To: <046.e54ca9bea7938e6373e7472a9ed47544@haskell.org> References: <046.e54ca9bea7938e6373e7472a9ed47544@haskell.org> Message-ID: <061.274b4d81c8dc192e6922f1018b662287@haskell.org> #8036: Demand analyser is unpacking too deeply -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #7520 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): I don't know how to test if this is fixed or not. Quite a few changes have been made to the file `stranal/DmdAnal.lhs` since. The mentioned `pprtrace` is still commented out, but there are many others commented out as well. This ticket is currently not listed on [wiki:Status/SLPJ- Tickets]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 03:16:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 03:16:52 -0000 Subject: [GHC] #8034: Missing ambiguity test for class methods In-Reply-To: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> References: <046.d8e44655b32c8bb4060972d42e5657d4@haskell.org> Message-ID: <061.becf54816430ceed01a17d2fbe821914@haskell.org> #8034: Missing ambiguity test for class methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 03:24:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 03:24:09 -0000 Subject: [GHC] #8031: Template Haskell gets confused with kind variables introduced in separate foralls In-Reply-To: <047.defe71e5e3f09763c5eefe74f7326e80@haskell.org> References: <047.defe71e5e3f09763c5eefe74f7326e80@haskell.org> Message-ID: <062.37972cbf26df670276d08c0a77ba5ed8@haskell.org> #8031: Template Haskell gets confused with kind variables introduced in separate foralls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: PolyKinds Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: TemplateHaskell PolyKinds => PolyKinds * component: Compiler => Template Haskell Comment: Module `S3` from the description compiles fine with 7.8.3 and HEAD, but not with 7.8.2. I think that means this ticket can be closed, once a regression test is added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 03:40:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 03:40:12 -0000 Subject: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.2644453921169933d07aa46328f40308@haskell.org> #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Type checker) | Keywords: Resolution: | Architecture: x86 Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * os: MacOS X => Unknown/Multiple Comment: {{{ $ sudo apt-get install p7zip $ 7zr x supabug.7z }}} Does anyone have an example that doesn't depend on `lens` or `yesod`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 03:43:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 03:43:18 -0000 Subject: [GHC] #8023: dph-examples binaries don't use all CPUs In-Reply-To: <048.47ff6e135b9fad50c544a0fe3766f9b8@haskell.org> References: <048.47ff6e135b9fad50c544a0fe3766f9b8@haskell.org> Message-ID: <063.12eccf93a10ec72d3d019616a357cac8@haskell.org> #8023: dph-examples binaries don't use all CPUs -------------------------------------+------------------------------------- Reporter: Lethalman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Data | Version: 7.6.3 Parallel Haskell | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: 7330 performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown Comment: Maybe a DPH guru can answer this question? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:03:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:03:25 -0000 Subject: [GHC] #8015: GHC is inconsistent about where LANGUAGE is unsupported. In-Reply-To: <052.80e9f802aa47ad1a9f1f9f5e61f57a60@haskell.org> References: <052.80e9f802aa47ad1a9f1f9f5e61f57a60@haskell.org> Message-ID: <067.3356f73611556b56f97e4d037a34a6b8@haskell.org> #8015: GHC is inconsistent about where LANGUAGE is unsupported. -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: parser Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: GHC accepts invalid program => Incorrect warning at compile- time Comment: From the [https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/pragmas.html users guide]: > "A file-header pragma must precede the module keyword in the file." > "The file-header pragmas are: {-# LANGUAGE #-}, {-# OPTIONS_GHC #-}, and {-# INCLUDE #-}." So the scope of this ticket should in my opinion be: when any file-header pragma (not only an unsupported language pragma) is used after the module keyword, ghc should show a warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:03:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:03:30 -0000 Subject: [GHC] #9777: -msse flag could be handled better by the driver In-Reply-To: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> References: <048.88cd2728642e9e3324eafc4b0b8a5a49@haskell.org> Message-ID: <063.93ca855d2b91e5a19f0cb959a00f29f2@haskell.org> #9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: dredozubov Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8404 Differential Revisions: Phab:D504 | -------------------------------------+------------------------------------- Comment (by carter): hrm, you might be right. It seems to be true for intel and amd cpus at least. Question: how do clang and GCC handle this logic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:06:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:06:10 -0000 Subject: [GHC] #8015: Show warning when file-header pragma is used after module keyword (was: GHC is inconsistent about where LANGUAGE is unsupported.) In-Reply-To: <052.80e9f802aa47ad1a9f1f9f5e61f57a60@haskell.org> References: <052.80e9f802aa47ad1a9f1f9f5e61f57a60@haskell.org> Message-ID: <067.57c898f4e205756f80f07c3c34310682@haskell.org> #8015: Show warning when file-header pragma is used after module keyword -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: feature | Milestone: request | Version: 7.6.3 Priority: normal | Keywords: parser Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Incorrect | warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request Comment: thoughtpolice: please correct me if I misinterpreted this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:12:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:12:07 -0000 Subject: [GHC] #8014: Assertion failure when using multithreading in debug mode. In-Reply-To: <047.0dcf2e2192ba50c19f85f9a1379ffc34@haskell.org> References: <047.0dcf2e2192ba50c19f85f9a1379ffc34@haskell.org> Message-ID: <062.5956c411c3e351f422fb9771b24753d9@haskell.org> #8014: Assertion failure when using multithreading in debug mode. -------------------------------------------+------------------------------ Reporter: Maxander | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.2 Resolution: | Keywords: rts Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7189 Differential Revisions: | -------------------------------------------+------------------------------ Changes (by thomie): * cc: simonmar (added) * component: Compiler => Runtime System Comment: Maxander: did you manage to find a way to reproduce this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:13:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:13:54 -0000 Subject: [GHC] #7189: RTS Assertion Crash In-Reply-To: <049.e87f12b64ebaa9191bcfa3650eeea1a7@haskell.org> References: <049.e87f12b64ebaa9191bcfa3650eeea1a7@haskell.org> Message-ID: <064.c8b70bb9480b0a86b75ffc7071bf5b78@haskell.org> #7189: RTS Assertion Crash -------------------------------------+------------------------------------- Reporter: sseverance | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.4.2 System | Keywords: Resolution: duplicate | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #8014 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => duplicate Comment: Closing as a duplicate of #8014. Alas, we still don't have any way to reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:22:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:22:04 -0000 Subject: [GHC] #7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x In-Reply-To: <047.88b56f359408533f50983a91b9a9fb88@haskell.org> References: <047.88b56f359408533f50983a91b9a9fb88@haskell.org> Message-ID: <062.b68e0350520e768b551d073851a3a21b@haskell.org> #7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x -----------------------------------------+------------------------------ Reporter: cjwatson | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------ Changes (by thomie): * status: new => infoneeded Comment: Does this problem still occur with 7.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:25:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:25:59 -0000 Subject: [GHC] #7990: ghc-pkg warning shows the wrong command In-Reply-To: <046.91afb6986132f7c4f597d8b349da0ac4@haskell.org> References: <046.91afb6986132f7c4f597d8b349da0ac4@haskell.org> Message-ID: <061.77c40784ce8c566e3df2b358c3153b59@haskell.org> #7990: ghc-pkg warning shows the wrong command -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package | Version: 7.6.3 system | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #9606 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => duplicate * related: => #9606 Comment: Great suggestion. I'm going to close as duplicate of #9606, although yours was first! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:31:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:31:06 -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.73a1fc7e7156247cb8514e024ccfa054@haskell.org> #7985: Allow openFile on unknown file type -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: ekmett Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Core | Version: 7.6.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * difficulty: => Unknown * status: new => infoneeded Comment: singpolyma: could you please give an example that currently fails, and which you would like to succeed. I'm not sure what you mean by 'special file type'. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:39:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:39:10 -0000 Subject: [GHC] #7983: Bug in hsc2hs --cross-safe In-Reply-To: <049.3ff36c949c6061d8d14e6939f732b877@haskell.org> References: <049.3ff36c949c6061d8d14e6939f732b877@haskell.org> Message-ID: <064.55529f85a6152cb775c8849b6e0b3f1e@haskell.org> #7983: Bug in hsc2hs --cross-safe -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: hsc2hs | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown Comment: This is the error with HEAD (ghc-7.9.20141121): {{{ $ cat test.hsc #define U_NO_NUMERIC_VALUE ((double)-123456789.) (#const U_NO_NUMERIC_VALUE) $ hsc2hs --cross-safe test.hsc $ hsc2hs --cross-compile test.hsc test.hsc: In function ?_hsc2hs_test2?: test.hsc:3:20: error: storage size of ?test_array? isn?t constant compilation failed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:44:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:44:40 -0000 Subject: [GHC] #7977: Optimization: Shift dropped list heads by coeffecient to prevent thunk generation In-Reply-To: <046.83197912499d0e3967eb4c87da663ec2@haskell.org> References: <046.83197912499d0e3967eb4c87da663ec2@haskell.org> Message-ID: <061.033ecec2eddc1ba04d5205f0029769d7@haskell.org> #7977: Optimization: Shift dropped list heads by coeffecient to prevent thunk generation -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: ? Priority: low | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug Comment: Not technically a "Runtime performance bug", but easier to find this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 04:57:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 04:57:51 -0000 Subject: [GHC] #7956: ghci segfaults with -vN command-line options In-Reply-To: <046.0ff627c810187a8eccd5ddacca68b657@haskell.org> References: <046.0ff627c810187a8eccd5ddacca68b657@haskell.org> Message-ID: <061.4e5edc0c46dcbedb0946323976cfe3a3@haskell.org> #7956: ghci segfaults with -vN command-line options -------------------------------------+------------------------------------- Reporter: mvanier | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: ghci, -v0, Operating System: MacOS X | segfault Type of failure: GHCi crash | Architecture: Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => worksforme Comment: hvanhier: sorry to hear you ran into this. Please try the ghci shipped with ghc 7.8.3, it should give you less problems on Mac OS X. But do re- open this ticket if it's still not working for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 05:08:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 05:08:22 -0000 Subject: [GHC] #7949: Haskell Platform doesn't build on Fedora 17 In-Reply-To: <045.c23bafc8b668987cc9bcc5a8e47d3508@haskell.org> References: <045.c23bafc8b668987cc9bcc5a8e47d3508@haskell.org> Message-ID: <060.d33a54dd2f6f296ad7592175571305bd@haskell.org> #7949: Haskell Platform doesn't build on Fedora 17 -------------------------------------+------------------------------------ Reporter: photex | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Sorry to hear you had this problem. Please try the latest [https://www.haskell.org/platform/linux.html release] of the Haskell Platform and report any installation issues you might have in the [https://github.com/haskell/haskell-platform issue tracker]. It should work on both Fedora as Ubuntu. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 05:13:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 05:13:14 -0000 Subject: [GHC] #7947: Name conflict with DerivingDataTypeable, StandaloneDeriving and qualified imports In-Reply-To: <047.12b570c09cfb6a6e5d35ce562b9ab002@haskell.org> References: <047.12b570c09cfb6a6e5d35ce562b9ab002@haskell.org> Message-ID: <062.26ac2a070b307bfbbd41a999e9962ec2@haskell.org> #7947: Name conflict with DerivingDataTypeable, StandaloneDeriving and qualified imports -------------------------------------+------------------------------------- Reporter: a.ulrich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 05:16:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 05:16:58 -0000 Subject: [GHC] #7934: usleep hangs, no threads In-Reply-To: <046.d121f779cb2c7e3c2c6772b604e9540c@haskell.org> References: <046.d121f779cb2c7e3c2c6772b604e9540c@haskell.org> Message-ID: <061.9323a442ac2cd75e12fb6ed74d253278@haskell.org> #7934: usleep hangs, no threads -------------------------------------+------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.4.2 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: 1156 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * difficulty: => Unknown Comment: I can not reproduce this on Linux. gelisam: does it still occur with ghc 7.6.3 or 7.8.3 on Mac OS X? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 05:34:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 05:34:32 -0000 Subject: [GHC] #7928: GHC fails to terminate while compiling with optimization level 2 In-Reply-To: <055.5e12f490967583ad649664b167419770@haskell.org> References: <055.5e12f490967583ad649664b167419770@haskell.org> Message-ID: <070.14d17eef683da35564a2a6e2e5e14cc9@haskell.org> #7928: GHC fails to terminate while compiling with optimization level 2 -------------------------------------+------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: fixed | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #7898, #7944 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: I tried the `cabal` command from the description. ghc-7.6.3 indeed gets stuck at some point, although for me it happens in the last step, when it is compiling `random-fu` itself. With ghc-7.8.3 I do manage to install `random-fu` however, so I'm calling this one fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 05:43:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 05:43:02 -0000 Subject: [GHC] #7926: eventfd: unsupported operation when doing anything In-Reply-To: <044.ea70c9e735dc66ad8ed89d7f534ebe35@haskell.org> References: <044.ea70c9e735dc66ad8ed89d7f534ebe35@haskell.org> Message-ID: <059.1eefacc0498be2b248579fcb467c6fd8@haskell.org> #7926: eventfd: unsupported operation when doing anything ----------------------------------------+---------------------------------- Reporter: guest | Owner: AndreasVoellmy Type: bug | Status: closed Priority: low | Milestone: ? Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Since we haven't had any new reports on this, and the `eventfd` bug report mentioned in comment:7 was later closed for being a kernel bug, I'm closing this issue. Please re-open if there are still problems running ghc or ghci on Debian Jessie. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 05:49:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 05:49:55 -0000 Subject: [GHC] #7908: InstanceSigs suggestion not accepted In-Reply-To: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> References: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> Message-ID: <063.651edc36ea3e34c583e55b3f552baca6@haskell.org> #7908: InstanceSigs suggestion not accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 06:08:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 06:08:13 -0000 Subject: [GHC] #7928: GHC fails to terminate while compiling with optimization level 2 In-Reply-To: <055.5e12f490967583ad649664b167419770@haskell.org> References: <055.5e12f490967583ad649664b167419770@haskell.org> Message-ID: <070.6f58039c3b4f15122541acada806271c@haskell.org> #7928: GHC fails to terminate while compiling with optimization level 2 -------------------------------------+------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: fixed | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #7898, #7944 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Ptharien's Flame, can you confirm that this works for you with GHC 7.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 08:20:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 08:20:26 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.d670a2517d95dd8d155817e96c16f78d@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): "I'm sorry, but I don't understand your request. The dictionary for IntLike would look something like this: data IntLikeDict a = MkIntLikeDict { fromInt :: Int -> a ; toInt :: a -> Int } There isn't an actual number stored anywhere. And, in fact, my example has made things more complicated than they really are. The dictionary type within GHC is IntLike -- there's no separate dictionary type." Yeah, I know, I just thought it would be obvious that I meant like, prependending the from/toInts with a lambda involving the first argument. Does the Dict method grant you access to the fromInt/toInt methods for each type? I.e. can you obtain, say, an IntLikeDict [Char] containing the functions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 08:20:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 08:20:55 -0000 Subject: [GHC] #8572: Building an empty module with profiling requires profiling libraries for integer-gmp In-Reply-To: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> References: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> Message-ID: <059.285cb5ca6cc507a919d15833ace6a848@haskell.org> #8572: Building an empty module with profiling requires profiling libraries for integer-gmp -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: simonpj (added) Comment: tbh, I've got a bad gut feeling too... this should be fixed properly, but I'm not sure how yet... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 09:16:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 09:16:37 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions In-Reply-To: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> References: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> Message-ID: <062.42fe4a8ac1d4268a160e23eba9f35a76@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T9318 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"888d75c80bf422cd4d67c44eadce7bdfe5133633/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="888d75c80bf422cd4d67c44eadce7bdfe5133633" Revert "Test Trac #9318" This reverts commit 5760eb598e0dfa451407195f15072204c15233ed because the very same test was already added via 5eebd990ea7a5bc1937657b101ae83475e20fc7a and is causing `./validate` to fail due to "framework failure". }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 09:21:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 09:21:22 -0000 Subject: [GHC] #9826: add Storable Complex and Ratio instance to base library In-Reply-To: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> References: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> Message-ID: <060.f4d8114aaeafdb1b08b280d1758e5c56@haskell.org> #9826: add Storable Complex and Ratio instance to base library -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D519 | -------------------------------------+------------------------------------- Comment (by hvr): please add links to the libraries/CLC discussion threads in the ticket- description -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 11:31:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 11:31:32 -0000 Subject: [GHC] #7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x In-Reply-To: <047.88b56f359408533f50983a91b9a9fb88@haskell.org> References: <047.88b56f359408533f50983a91b9a9fb88@haskell.org> Message-ID: <062.4c1a9446624fbdea346cb33b5c5e0ad6@haskell.org> #7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x -----------------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: Other Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------- Changes (by nomeata): * status: infoneeded => closed * resolution: => worksforme Comment: At least ghc itself seems to build fine: https://buildd.debian.org/status/package.php?p=ghc&suite=experimental I did not yet try to upload separate packages to be built with this. I guess we can close/ignore this for now, and revisit if it occurs again with 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 12:23:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 12:23:33 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.de76ed16cd1699b8fd438faac722c173@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"2b71b355fb1eb559243444f2dc4584e591fddee1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2b71b355fb1eb559243444f2dc4584e591fddee1" Remove reference to `MIN_VERSION_integer_gmp2` This is slipped in by accident as part of c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a (re #9281) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 12:23:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 12:23:33 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.a4994992b85fb3ec4804e7bf236f7ed9@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"be7fb7e58c70cd9b0a933fb26cd5f2607d6dc4b2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="be7fb7e58c70cd9b0a933fb26cd5f2607d6dc4b2" integer-gmp2: export `Word`-counterpart of gcdInt It's trivial for `integer-gmp2` (#9281) to provide it, and it'll be useful for a future 'Natural'-related commit, as well as providing a `Word` optimised `gcd`-RULE. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 14:20:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 14:20:45 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.34944088cc39d4a3042e90c03da8cfc4@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"4b6537677fa9460ca5febe2eb79a2d9d5bdadba2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4b6537677fa9460ca5febe2eb79a2d9d5bdadba2" Add `isValidNatural` predicate (#9818) This predicate function encodes the internal `Natural` invariants, and is useful for testsuites or code that directly constructs `Natural` values. C.f. `integer-gmp2`'s `isValidBigNat#` and `isValidInteger#` predicates for testing internal invariants. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 14:20:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 14:20:46 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.2901e7504ec8d2e69924c652764e3734@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"b836139099fc203a8b94849655d7dfb95dd80f4a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b836139099fc203a8b94849655d7dfb95dd80f4a" Fix `fromInteger` constructing invalid `Natural` This fixes a case where `isValidNatural . fromInteger` would be `False`. Re #9818 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 14:20:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 14:20:46 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.6e5734e8e21676584636d89854cf1c6f@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"41300b7687c7fc60832f5fa91fce897fc2679ccd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="41300b7687c7fc60832f5fa91fce897fc2679ccd" Implement {gcd,lcm}/Natural optimisation (#9818) This provides the equivalent of the existing `{gcd,lcm}/Integer` optimisations for the `Natural` type, when using the `integer-gmp2` backend. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 14:20:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 14:20:46 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.2200a9bac372bf8042c58acdec0014e6@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"96d29b5403bd8a6465a65a39da861f5b9610fc89/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="96d29b5403bd8a6465a65a39da861f5b9610fc89" Call `popCountBigNat` directly (#9818) This calls the `popCountBigNat` primitive directly instead of going through `Integer`'s `popCount`. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 15:49:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 15:49:11 -0000 Subject: [GHC] #9826: add Storable Complex and Ratio instance to base library In-Reply-To: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> References: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> Message-ID: <060.b04de3d793b7bab8ff66bd7ac6d78302@haskell.org> #9826: add Storable Complex and Ratio instance to base library -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D519 | -------------------------------------+------------------------------------- Description changed by carter: Old description: > per the libraries discussion + core libraries committee OK, > I'm putting a phab differential up for adding Storable instances for > Complex and Ratio > > (and then noticing that theres basically NO tests for Storable except > indirectly) New description: per the libraries discussion + core libraries committee OK, I'm putting a phab differential up for adding Storable instances for Complex and Ratio (and then noticing that theres basically NO tests for Storable except indirectly) the libraries thread for Complex and Ratio https://www.haskell.org/pipermail/libraries/2014-November/024064.html the thread on the CLC list https://groups.google.com/forum/#!topic /haskell-core-libraries/mjBSo2CQ3LU -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 17:12:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 17:12:40 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.f0d0d5fe443833d6e83e21505bd2a488@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D337 | -------------------------------------+------------------------------------- Comment (by kolmodin): With the patch 624a7c5a2eee0c0ba486a45550680052c2c79849 mentioned above, the bulk of the work is done. What remains is to; - Clean up DynFlags, a lot of the lines are over 80 chars - Let more people look at the partitioning of the flags into ghc/ghci/all, correcting any mistakes where a flag has been assigned to the wrong mode - Some flags are defined in DynFlags but not documented in the User's Guide. Should they be marked as hidden? Mail ghc-devs and find out. - Possibly update documentation about ghc's new ability to use --interactive and --show-options together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 17:58:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 17:58:02 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.8f0f3cf33b46dd52b8817b4d9c106afe@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9286,#8756,#7876 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #9286,#8756 => #9286,#8756,#7876 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 17:59:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 17:59:30 -0000 Subject: [GHC] #7876: hClose002 for ghci hangs on Mac OS X In-Reply-To: <046.3aeffa21c09f90c81c4fecee3401f75b@haskell.org> References: <046.3aeffa21c09f90c81c4fecee3401f75b@haskell.org> Message-ID: <061.7428355e6cd7ae680ac9ea0e67e0869a@haskell.org> #7876: hClose002 for ghci hangs on Mac OS X -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: #9389 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * component: Compiler => Test Suite * resolution: => duplicate * related: => #9389 Comment: I'm combining test suite failures for OS X in #9389. I added a link back to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 18:00:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 18:00:50 -0000 Subject: [GHC] #7877: hSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X In-Reply-To: <046.92d791d23cf97616f743a1cfd8144868@haskell.org> References: <046.92d791d23cf97616f743a1cfd8144868@haskell.org> Message-ID: <061.97e9aed51e340e60f38cbe876e3ada5e@haskell.org> #7877: hSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: #9389 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * component: GHCi => Test Suite * resolution: => duplicate * related: => #9389 Comment: I'm combining test suite failures for OS X in #9389. I added a link back to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 18:01:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 18:01:26 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.c6c567cc66508b683303d4b20b993976@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | #9286,#8756,#7876,#7877 -------------------------------------+------------------------------------- Changes (by thomie): * related: #9286,#8756,#7876 => #9286,#8756,#7876,#7877 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 18:11:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 18:11:22 -0000 Subject: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp' In-Reply-To: <046.cf50459cade182946253e5602ab21f1f@haskell.org> References: <046.cf50459cade182946253e5602ab21f1f@haskell.org> Message-ID: <061.9ac1cdbea4c216789b4892f642df447f@haskell.org> #7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Driver | Keywords: gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #3489 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * component: Core Libraries => Driver Comment: hvr: is this feature request still relevant after the integer-gmp rewrite (#9281)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 18:22:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 18:22:46 -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.55ecf30e6075d40a742761c182a2bef4@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: > ... it might break some existing programs which are inadvertently straying from H98 definition. > > So I'm rather inclined to let sleeping dogs lie. Closing as wontfix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 18:23:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 18:23:33 -0000 Subject: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp' In-Reply-To: <046.cf50459cade182946253e5602ab21f1f@haskell.org> References: <046.cf50459cade182946253e5602ab21f1f@haskell.org> Message-ID: <061.5517c3a0deca1d9ac545fdae6612339a@haskell.org> #7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: gmp Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3489 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * owner: ekmett => * component: Driver => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 18:31:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 18:31:26 -0000 Subject: [GHC] #7849: Error on pattern matching of an existential whose context includes a type function In-Reply-To: <044.feb780304d12ddb9926c7105b359e0b9@haskell.org> References: <044.feb780304d12ddb9926c7105b359e0b9@haskell.org> Message-ID: <059.6fbe9239249bc73c96f0e6f05488851b@haskell.org> #7849: Error on pattern matching of an existential whose context includes a type function -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * milestone: => 7.10.1 Comment: With HEAD (ghc-7.9.20141121), the error message is still the same, except for these 2 extra lines: {{{ Expected type: IO b0 Actual type: IO () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 18:38:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 18:38:48 -0000 Subject: [GHC] #7842: Incorrect checking of let-bindings in recursive do In-Reply-To: <047.6ed6f6679c4518c532948e013c23eaed@haskell.org> References: <047.6ed6f6679c4518c532948e013c23eaed@haskell.org> Message-ID: <062.ad1ac8aa1d1969a7e2e407f9b4db1104@haskell.org> #7842: Incorrect checking of let-bindings in recursive do -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown Comment: This ticket is listed on the page of [wiki:Status/SLPJ-Tickets tickets] that SPJ is interested in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 18:51:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 18:51:38 -0000 Subject: [GHC] #9640: Invalid object in processHeapClosureForDead(): 2130762223 In-Reply-To: <047.4251ac36032806c0b7c6a3cfadb392fc@haskell.org> References: <047.4251ac36032806c0b7c6a3cfadb392fc@haskell.org> Message-ID: <062.0091ae114066c27babaef4ea6b824051@haskell.org> #9640: Invalid object in processHeapClosureForDead(): 2130762223 -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #7836 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #7836 Comment: Closing in favor of #7836. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 18:55:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 18:55:09 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb (was: Runtime failure profiling with +RTS -hc -hbdrag, void) In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.ba64ee938b75cea6e28032aca80632d5@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #9640 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #9640 Comment: See #9640 for a report of this problem when profiling `Yi` with 7.8.3. I don't think this is an OS X only problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 19:24:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 19:24:49 -0000 Subject: [GHC] #7803: Superclass methods are left unspecialized In-Reply-To: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> References: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> Message-ID: <058.a1161286a413ae18ef113d67af27d6d0@haskell.org> #7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Simon's suggestion change from comment:3 did not make it into the [https://github.com/ghc/ghc/blob/96d29b5403bd8a6465a65a39da861f5b9610fc89/compiler/simplCore/SimplCore.lhs#L179 ghc codebase]. I am not sure what the status of this ticket is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 19:35:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 19:35:01 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.64d61b5c03e5ca378375a2df1a4c002b@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high Comment: The program from the description compiles fine with 7.8.3. GHC HEAD (ghc-7.9.20141121) however uses a huge amount of memory very quickly until I have to kill the process. It seems to never get past the `Renamer/typechecker` phase. This looks like a regression, setting priority to high. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 19:55:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 19:55:16 -0000 Subject: [GHC] #7789: GHCI core dumps when used with VTY In-Reply-To: <049.b36182eedf1c6058b38f280d542dcf30@haskell.org> References: <049.b36182eedf1c6058b38f280d542dcf30@haskell.org> Message-ID: <064.af063afbf11fe729f5b4242a9709a221@haskell.org> #7789: GHCI core dumps when used with VTY -------------------------------------+------------------------------------- Reporter: timthelion | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.2-rc1 Resolution: | Keywords: core dump Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Can reproduce on Linux 64 with 7.8.3. To reproduce the segmentation fault: {{{ $ cabal install vty-menu $ ghci -fno-ghci-sandbox ghci-coredumper.hs Prelude> die # Hold the Enter key for 10-30 seconds. }}} Replacing the second step by just `ghci ghci-coredumper.hs`, I sometimes get: {{{ *** Error in `/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3/bin/ghc': double free or corruption (fasttop): 0x00007f65b00118c0 *** Aborted (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 20:02:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 20:02:11 -0000 Subject: [GHC] #7767: "internal error: evacuate: strange closure type 154886248" crash In-Reply-To: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> References: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> Message-ID: <062.de6b49a6e8bf394b73d147b675c3d129@haskell.org> #7767: "internal error: evacuate: strange closure type 154886248" crash -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: invalid | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => invalid Comment: Replying to [comment:11 carter]: > So this ticket it about the possibility of exposing a GHC api to better support writing Heap introspection tools right? > > Should we split that out into its own ticket as a somewhat clearer feature request that cites this ticket? Yes, could somebody please do that, if it's still necessary. A feature request with the title "internal error: evacuate: strange closure type 154886248" is very confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 20:16:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 20:16:11 -0000 Subject: [GHC] #7763: Resource limits for Haskell In-Reply-To: <045.162cb8dcc1da76bcf52a024b86650210@haskell.org> References: <045.162cb8dcc1da76bcf52a024b86650210@haskell.org> Message-ID: <060.a765c150581ad98b7c7b3bb006e8ad12@haskell.org> #7763: Resource limits for Haskell -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Profiling | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #5476 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #5476 Comment: See also http://ezyang.com/rlimits.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 20:20:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 20:20:31 -0000 Subject: [GHC] #7741: Add SIMD support to x86/x86_64 NCG In-Reply-To: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> References: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> Message-ID: <062.03f7fb4254413bf97455828cb1cc1ed6@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: (NCG) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3557 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (NCG) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 20:28:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 20:28:31 -0000 Subject: [GHC] #7078: Panic using mixing list with parallel arrays incorrectly In-Reply-To: <044.030e5d4d61c7c476d0a2818f005be597@haskell.org> References: <044.030e5d4d61c7c476d0a2818f005be597@haskell.org> Message-ID: <059.ea7ac8d849399c58e911d399124996be@haskell.org> #7078: Panic using mixing list with parallel arrays incorrectly ---------------------------------------------+--------------------------- Reporter: NeilJ | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7736 Differential Revisions: | ---------------------------------------------+--------------------------- Changes (by thomie): * related: => #7736 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 20:28:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 20:28:35 -0000 Subject: [GHC] #7736: Parallel array enumeration causes compiler panic (enumFromToP) In-Reply-To: <051.4008212f128c07df40f2414b51ea0564@haskell.org> References: <051.4008212f128c07df40f2414b51ea0564@haskell.org> Message-ID: <066.42af3e0ad914404dc1bcdae8ed48b7df@haskell.org> #7736: Parallel array enumeration causes compiler panic (enumFromToP) -------------------------------------+------------------------------------- Reporter: | Owner: chak amosrobinson | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #7078 time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Smaller testcase: {{{ $ cat EnumFromToP.hs {-# LANGUAGE ParallelArrays #-} module EnumFromToP where nums = [: 0 .. 100 :] $ ghc-7.9.20141121 EnumFromToP.hs [1 of 1] Compiling EnumFromToP ( EnumFromToP.hs, EnumFromToP.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141121 for x86_64-unknown-linux): DsMonad: uninitialised ds_parr_bi }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 20:57:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 20:57:10 -0000 Subject: [GHC] #7727: Nonsense evaluation: sequence [] = [] In-Reply-To: <045.21411a044b46ebf042a3b533aaca43a4@haskell.org> References: <045.21411a044b46ebf042a3b533aaca43a4@haskell.org> Message-ID: <060.3969d5e3cb7936e1e4aae384769f5baa@haskell.org> #7727: Nonsense evaluation: sequence [] = [] -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.6.2 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9748 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * status: new => closed * resolution: => invalid * related: => #9748 Comment: See #9748 for a recent proposal to display something like this instead: {{{ >>> sequence [] [] >>> :t it it :: {- IO -} [()] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 21:00:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 21:00:58 -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.d0e15f57eaeadb6107f89683fd2e5ce3@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: closed => new * resolution: wontfix => Comment: Sorry for reopening, but I think the situation can be improved, currently `-XConstrainedClassMethods` seems to do nothing and the documentation is misleading. I would support deprecating and eventually removing this pragma, and adding a notice to "Known bugs and infelicities" section. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 21:06:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 21:06:53 -0000 Subject: [GHC] #9748: Disambiguate IO actions in GHCi with :set +t In-Reply-To: <051.eb64c51829f1760c379502433f79e297@haskell.org> References: <051.eb64c51829f1760c379502433f79e297@haskell.org> Message-ID: <066.2183647fb71156ed257e0dca7abba304@haskell.org> #9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: | Owner: zudov Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: low | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): I like Herbert's suggestion too. See #7727 for a user report which could have been prevented if this feature got implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 21:19:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 21:19:45 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.18a8a486625b406e8987d6b4e8da9e31@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm not sure what you mean by "grant access"... but perhaps this will help: When you pattern match on the `Dict` constructor, you get the `c` constraint in the context. So, the following is conceivable: {{{ -- this type is actually from ekmett's "constraints" package data Dict c where Dict :: c => Dict c class IntLike a where fromInt :: Int -> a toInt :: a -> Int dictForIntLikeString :: Dict (IntLike String) dictForIntLikeString = ... stringToInt :: String -> Int stringToInt s = case dictForIntLikeString of Dict -> toInt s }}} Note that there is no `instance IntLike String` around -- the reason `toInt` can be called in `stringToInt` is because of the pattern-match on `Dict`. Now, this example falls apart because the implementation of `dictForIntLikeString` seems impossible without a `instance IntLike String` dictionary available. But perhaps this answers your question about what `Dict` can do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 21:35:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 21:35:29 -0000 Subject: [GHC] #7723: iOS patch no 12: Itimer.c doesn't work on iOS In-Reply-To: <056.9767e70565312fbbb95062bfdcdf193a@haskell.org> References: <056.9767e70565312fbbb95062bfdcdf193a@haskell.org> Message-ID: <071.ee560090a4804e0b3a6ddb99e267b836@haskell.org> #7723: iOS patch no 12: Itimer.c doesn't work on iOS --------------------------------------------+------------------------------ Reporter: StephenBlackheath | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Other | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | --------------------------------------------+------------------------------ Comment (by thomie): StephenBlackheath: could you try to see what happens when you revert this workaround, with a current version of Xcode? It would be nice to remove it if it's not needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 21:43:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 21:43:51 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.cadf267ef1c0ddcb005e0eafd084baaf@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Runtime | than a day) crash | Blocked By: Test Case: | Related Tickets: #8977 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This bug seems to be fixed in HEAD (ghc-7.9.20141121), although I can not find the commit that might have fixed it. We should probably add a regression test before closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 21:52:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 21:52:09 -0000 Subject: [GHC] #7665: dynamicToo001 fails on Windows In-Reply-To: <044.f13a713c3c51866752802a506a231ea6@haskell.org> References: <044.f13a713c3c51866752802a506a231ea6@haskell.org> Message-ID: <059.1fb60640fef9c6c5c62773c72131e836@haskell.org> #7665: dynamicToo001 fails on Windows -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 22:18:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 22:18:44 -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.e3f55ce4417a18fe6dba9317c261dac2@haskell.org> #9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8627 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): {{{ [14/11/22-17:13:25] the posix_memalign thing is probably the right fix [14/11/22-17:13:37] that'd ensure that malloc aligns to whatever boundary the actual storable requires [14/11/22-17:13:50] so when folks make data types for SIMD blocks of floats they work right [14/11/22-17:14:30] in theory it could affect even old x86 stuff with the old 10 byte long doubles [14/11/22-17:14:35] which want a 16 byte alignment }}} notes by edward for this ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 22 22:40:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Nov 2014 22:40:29 -0000 Subject: [GHC] #7643: Kind application error In-Reply-To: <048.a03d3c055f589ce6d978bf10fc16a0fa@haskell.org> References: <048.a03d3c055f589ce6d978bf10fc16a0fa@haskell.org> Message-ID: <063.72cc5eaab43c75003094c36b3bb802ba@haskell.org> #7643: Kind application error -------------------------------------+------------------------------------- Reporter: gmainland | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7354, #8355 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): The example from the description, as well as the simpler testcase from comment:1, both compile fine with ghc 7.8.1 and higher: {{{ $ ghc-7.8.1 -dcore-lint -package primitive --make Main.hs }}} (without `-package primitive` I'm getting "undefined reference to `hsprimitive_memset_Word`" errors) A regression test should probably be added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 00:34:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 00:34:59 -0000 Subject: [GHC] #9827: void does not use <$ Message-ID: <045.4f2c1a8cabbc326e3b87132d0e33ca05@haskell.org> #9827: void does not use <$ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D521 -------------------------------------+------------------------------------- `Data.Functor.void` is currently defined as {{{#!hs void = fmap (const ()) }}} Some `Functor` instances have an optimized `<$`, so this should be {{{#!hs void x = () <$ x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 03:02:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 03:02:43 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.d6578ee9deae57a3c6cf7e8b1bc4f126@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Essentially, I'm looking for a method to automate the process of defining the Def data function in the ReifiableConstraint class in here: https://www.fpcomplete.com/user/thoughtpolice/using-reflection#turning-up- the-magic-to-over-9000 for arbitrary constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 04:19:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 04:19:17 -0000 Subject: [GHC] #9827: void does not use <$ In-Reply-To: <045.4f2c1a8cabbc326e3b87132d0e33ca05@haskell.org> References: <045.4f2c1a8cabbc326e3b87132d0e33ca05@haskell.org> Message-ID: <060.acb6feb2f063bdbb56497d02668b0dfa@haskell.org> #9827: void does not use <$ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D521 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 06:32:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 06:32:24 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.dd25c44c0f8215a3272b05644dcb0bc1@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: carter MikeIzbicki | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Changes (by carter): * status: new => patch Comment: ok, i've fixed up the design into one thats a) simpler b) more general c) easier to use its not perfect, but should be decent for 7.10 purposes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 07:56:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 07:56:01 -0000 Subject: [GHC] #9828: genprimopcode: parse error Message-ID: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> #9828: genprimopcode: parse error ----------------------------+---------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- Building git HEAD on powerpc-linux I get: {{{ "inplace/bin/genprimopcode" --data-decl < compiler/stage1/build/primops.txt > compiler/stage1/build/primop-data-decl.hs-incl genprimopcode: parse error at "Parse error at line 42, column 8" }}} If I look at line 42 of `compiler/stage1/build/primops.txt` I see: {{{ -- SCALAR_TYPE is the scalar type used to inject to/project from vector }}} The word "vector" from the comment got wrapped onto the next line for no good reason. I've checked the file `compiler/prelude/primops.txt.pp` which is processed to generate the file I'm having problems with and that file is fine. I've cloned a new copy of the repo and done the usual `perl boot && ./configure && make` only to see exactly the same result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 08:27:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 08:27:54 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.a85f9e6c1d0cd873fb79c8acf2150bd4@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: carter MikeIzbicki | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Comment (by carter): note that its not seq-like yet for this reelase, but rather doing the state token passing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 11:57:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 11:57:16 -0000 Subject: [GHC] #9829: Installed signal handlers are not cleared up by GHC API Message-ID: <046.12e1017badb2cae4bd63bf8d84aea400@haskell.org> #9829: Installed signal handlers are not cleared up by GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When using runGHC, it calls installSignalHandlers which installs a bunch of them. There is even an XXX comment in runGHC to uninstall these eventually. Generally, when using the GHC API, I wouldn't like it to install any signal handlers by default, if that is possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 15:06:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 15:06:46 -0000 Subject: [GHC] #7623: GHC Arm support In-Reply-To: <045.c35d52af4b1a6f0b21827ee05808397e@haskell.org> References: <045.c35d52af4b1a6f0b21827ee05808397e@haskell.org> Message-ID: <060.bbfa4ac86dcd311675f28f6932b39437@haskell.org> #7623: GHC Arm support -------------------------------------+------------------------------------- Reporter: dterei | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: duplicate | Keywords: Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: 7316, 7591, 7620, time crash | 7640 Test Case: | Related Tickets: #7637 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: Since nobody is updating this ticket, and an actually up-to-date list of open tickets concerning [https://ghc.haskell.org/trac/ghc/query?status=!closed&architecture=arm GHC on ARM] is a query away, I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 17:00:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 17:00:50 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.893ab77203b8aede113ae36b17232fdc@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #8977 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => * difficulty: Moderate (less than a day) => Unknown Comment: Replying to [comment:8 thomie]: > This bug seems to be fixed in HEAD (ghc-7.9.20141121), although I can not find the commit that might have fixed it. No, the bug ist still present in HEAD @96d29b5. I just verified on openSUSE 13.2 i586. Unfortunately, I don't have time to work on a fix right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 17:37:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 17:37:09 -0000 Subject: [GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics In-Reply-To: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> References: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> Message-ID: <061.67d81774f90a882ac904ff0a9cd8ab7d@haskell.org> #9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9043 Test Case: | Blocking: 9043 | Differential Revisions: Phab:D493 | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 17:37:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 17:37:26 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.f3018e5bd1feda789f7283c93ff8ae38@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #8977 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): > No, the bug ist still present in HEAD @96d29b5. I just verified on openSUSE 13.2 i586. > > Unfortunately, I don't have time to work on a fix right now. Strange. When I run the commands from the description with ghc-7.8.3, cpu goes indeed to 100% and the process never finishes. When I do the same with HEAD, everything works fine. I'm on Ubuntu 14.04 x86_64. trommler: do you maybe have a better test for this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 18:54:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 18:54:49 -0000 Subject: [GHC] #9829: Installed signal handlers are not cleared up by GHC API In-Reply-To: <046.12e1017badb2cae4bd63bf8d84aea400@haskell.org> References: <046.12e1017badb2cae4bd63bf8d84aea400@haskell.org> Message-ID: <061.f7f2ccfe3ebc2f0d26fef9cda74d084f@haskell.org> #9829: Installed signal handlers are not cleared up by GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 4162 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by literon): * status: new => closed * resolution: => duplicate * related: => 4162 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 18:58:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 18:58:35 -0000 Subject: [GHC] #4162: GHC API messes up signal handlers In-Reply-To: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> References: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> Message-ID: <064.960f534381344e8d99a4bd210488ee60@haskell.org> #4162: GHC API messes up signal handlers -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by literon): * difficulty: => Unknown Comment: I would appreciate if this were addressed. In particular, I use GHC API for typechecking only and don't intend to evaluate expressions. I would handle killing the GHC thread myself if needed so. At minimum, a documentation comment should be added to `runGhc` that it installs signal handlers without restoring them to spare people from surprises. Note that non-responsiveness to Ctrl-C can be worked around by using `runGHC $ installHandler sigINT Default Nothing >> ...`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 20:11:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 20:11:39 -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.1c9653d0c347490a235cb5d3d16392ab@haskell.org> #8274: Core pretty-printer doesn't print # on unboxed literals -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by detrumi): * owner: detrumi => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 21:02:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 21:02:31 -0000 Subject: [GHC] #9827: void does not use <$ In-Reply-To: <045.4f2c1a8cabbc326e3b87132d0e33ca05@haskell.org> References: <045.4f2c1a8cabbc326e3b87132d0e33ca05@haskell.org> Message-ID: <060.d2607cfcfd0007c9696fb1232fbc11c1@haskell.org> #9827: void does not use <$ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D521 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"cc7a735f015510dda6f69d4a48d1b0cdd55856ba/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cc7a735f015510dda6f69d4a48d1b0cdd55856ba" Define void using <$ (re #9827) `() <$ x` is sometimes better than `fmap (const ()) x` and should never be worse. Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D521 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 21:03:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 21:03:42 -0000 Subject: [GHC] #9827: void does not use <$ In-Reply-To: <045.4f2c1a8cabbc326e3b87132d0e33ca05@haskell.org> References: <045.4f2c1a8cabbc326e3b87132d0e33ca05@haskell.org> Message-ID: <060.b26f65fd4e51afa5e7e922051a0f9383@haskell.org> #9827: void does not use <$ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D521 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 21:23:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 21:23:10 -0000 Subject: [GHC] #9826: add Storable Complex and Ratio instance to base library In-Reply-To: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> References: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> Message-ID: <060.4116ca4d6c105bdd77fc301f8cbfc4de@haskell.org> #9826: add Storable Complex and Ratio instance to base library -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D519 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"fb061c193947a7096471486faade1d0db30bc588/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fb061c193947a7096471486faade1d0db30bc588" Add `Storable` instances for `Complex` and `Ratio` The actual type-signatures of the new instances are: instance Storable a => Storable (Complex a) instance (Storable a, Integral a) => Storable (Ratio a) See also https://groups.google.com/d/msg/haskell-core- libraries/mjBSo2CQ3LU/0gwg0QvviOIJ Addresses #9826 Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D519 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 21:41:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 21:41:58 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.a42dfa6bc973b2d5b4b7dcbe2aa4a3ce@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a9a0dd34dcdfb7309f57bda88435acca14ec54d5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a9a0dd34dcdfb7309f57bda88435acca14ec54d5" Install `ghc-gmp.h` C include header file (#9281) This is mostly interesting when using the in-tree GMP, as there's no way otherwise to access the in-tree `gmp.h` header file after installation. In case `integer-gmp2` was build against a system-installed GMP library, `ghc-gmp.h` simply contains `#include ` for convenience. Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D522 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 21:41:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 21:41:58 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.bc9d0a7d894be11a659bf80102e3a5e5@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"6d1c8ec79adf566d57d2c35aac8ff6635412d108/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6d1c8ec79adf566d57d2c35aac8ff6635412d108" Persist build-time GMP ver to `HsIntegerGmp.h` This creates the additional macro definitions in `HsIntegerGmp.h` which are useful for 3rd party `integer-gmp`-addon libraries. Here's an example for the definitions created for the in-tree GMP: #define GHC_GMP_INTREE 1 #define GHC_GMP_VERSION_MJ 5 #define GHC_GMP_VERSION_MI 0 #define GHC_GMP_VERSION_PL 4 #define GHC_GMP_VERSION (5 * 10000 + 0 * 100 + 4) And here's an example for a system-installed GMP: #define GHC_GMP_INTREE 0 #define GHC_GMP_VERSION_MJ 6 #define GHC_GMP_VERSION_MI 0 #define GHC_GMP_VERSION_PL 0 #define GHC_GMP_VERSION (6 * 10000 + 0 * 100 + 0) Part of #9281 Reviewed By: ekmett (via D522) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 23 23:08:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Nov 2014 23:08:16 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.54a79720804f0d921fc841e5270a2a67@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | #9286,#8756,#7876,#7877 -------------------------------------+------------------------------------- Comment (by merijn): `./validate --fast` on OSX 10.10 produced the following today: {{{ Unexpected results from: TEST="cabal01 T5435_dyn_asm subsections_via_symbols cabal06 T4801" OVERALL SUMMARY for test run started at Sat Nov 22 21:35:31 2014 PST 0:07:30 spent to go through 4230 total tests, which gave rise to 13843 test cases, of which 9956 were skipped 53 had missing libraries 3763 expected passes 66 expected failures 0 caused framework failures 0 unexpected passes 4 unexpected failures 1 unexpected stat failures Unexpected failures: cabal/cabal01 cabal01 [bad exit code] (normal) cabal/cabal06 cabal06 [bad stdout] (normal) llvm/should_run/subsections_via_symbols subsections_via_symbols [bad exit code] (normal) rts T5435_dyn_asm [bad stdout] (normal) Unexpected stat failures: perf/compiler T4801 [stat too good] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 00:46:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 00:46:52 -0000 Subject: [GHC] #7475: Mysterious Data.Word Segmentation Fault in GHCi In-Reply-To: <042.0d1079999ffac31cce4c009249dd86e7@haskell.org> References: <042.0d1079999ffac31cce4c009249dd86e7@haskell.org> Message-ID: <057.40b502727c5a185e60420ff7606b269f@haskell.org> #7475: Mysterious Data.Word Segmentation Fault in GHCi -------------------------------------+------------------------------------- Reporter: VKS | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: ghci, data.word, Operating System: MacOS X | segfault Type of failure: GHCi crash | Architecture: x86_64 (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: 3658 Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => fixed * milestone: 7.10.1 => Comment: This was fixed in or before version 7.8.3. Confirmed on 64 bit OS X by carter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 01:40:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 01:40:42 -0000 Subject: [GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example. In-Reply-To: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> References: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> Message-ID: <061.defd4aaadd2333eb6b33f0e7e8318df0@haskell.org> #7521: Simplifier ticks exhausted when compiling Accelerate example. -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Linux => Unknown/Multiple Comment: The file `accelerate-examples.cabal` in the latest version of that package (0.15.0.0) contains: {{{ if impl(ghc >= 7.6) ghc-options: -fsimpl-tick-factor=130 }}} When I remove those lines, trying to build the package with ghc-7.8.3 still results in a `Simplifier ticks exhausted` panic. Steps to reproduce: {{{ $ sudo apt-get install c2hs freeglut3-dev $ cabal get accelerate-examples==0.15.0.0 $ cd accelerate-examples $ cabal install --dependencies-only # `accelerate-cuda` might fail to install, just ignore that # edit `accelerate-examples.cabal` $ cabal build }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 01:59:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 01:59:42 -0000 Subject: [GHC] #9830: Standalone-derived Show instance for type constructor has different precedence if orphan instance Message-ID: <050.5a294db69b3f4b3a7a91abd307a8c2ef@haskell.org> #9830: Standalone-derived Show instance for type constructor has different precedence if orphan instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you are using {{{StandaloneDeriving}}} to derive a {{{Show}}} instance for a data type with an infix constructor, its precedence will be different depending on which module the {{{deriving instance ...}}} declaration is in. For example, with this code: {{{#!hs -- InfixShow.hs {-# LANGUAGE StandaloneDeriving #-} module InfixShow where infixr 6 :?: data ADT a b = a :?: b deriving (Eq, Ord, Read) deriving instance (Show a, Show b) => Show (ADT a b) }}} {{{#!hs -- Main.hs module Main where import InfixShow main :: IO () main = do putStrLn $ "Prec 6: " ++ showsPrec 6 ("test" :?: "show") "" putStrLn $ "Prec 7: " ++ showsPrec 7 ("test" :?: "show") "" putStrLn $ "Prec 9: " ++ showsPrec 9 ("test" :?: "show") "" putStrLn $ "Prec 10: " ++ showsPrec 10 ("test" :?: "show") "" }}} Calling {{{runhaskell Main.hs}}} will produce this output, as expected: {{{ Prec 6: "test" :?: "show" Prec 7: ("test" :?: "show") Prec 9: ("test" :?: "show") Prec 10: ("test" :?: "show") }}} However, if the code is changed so that the {{{deriving instance ...}}} declaration is in {{{Main.hs}}} instead: {{{#!hs -- InfixShow.hs module InfixShow where infixr 6 :?: data ADT a b = a :?: b deriving (Eq, Ord, Read) }}} {{{#!hs -- Main.hs {-# LANGUAGE StandaloneDeriving #-} module Main where import InfixShow deriving instance (Show a, Show b) => Show (ADT a b) main :: IO () main = do putStrLn $ "Prec 6: " ++ showsPrec 6 ("test" :?: "show") "" putStrLn $ "Prec 7: " ++ showsPrec 7 ("test" :?: "show") "" putStrLn $ "Prec 9: " ++ showsPrec 9 ("test" :?: "show") "" putStrLn $ "Prec 10: " ++ showsPrec 10 ("test" :?: "show") "" }}} Then the output of {{{runhaskell Main.hs}}} is different: {{{ Prec 6: "test" :?: "show" Prec 7: "test" :?: "show" Prec 9: "test" :?: "show" Prec 10: ("test" :?: "show") }}} This seems to indicate that {{{:?:}}} has the default application precedence (9) instead of the precedence defined in {{{InfixShow}}} (6). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 02:11:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 02:11:48 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info In-Reply-To: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> References: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> Message-ID: <060.d6d2d6d369f5e8ad09f6a964351d0953@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ian_mi): * status: infoneeded => new Comment: Sorry for the delay, here is how this bug can be reproduced: 1. Clone the extended-categories package from https://github.com/ian-mi /extended-categories and checkout tag `0.2.0`. 2. Install the dependencies `tagged` and `constraints` into a sandbox if not already available. 3. Download the attached `Bug9574.hs` file. 3. Using GHC 7.8.3, load extended-categories into ghci using `cabal repl` and then load `Bug9574.hs`. Please let me know if you need any additional information. Thanks, Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 04:08:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 04:08:43 -0000 Subject: [GHC] #9828: genprimopcode: parse error In-Reply-To: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> References: <044.4f61a9262a17977cdef988ddc024706a@haskell.org> Message-ID: <059.7054c75cd9ffef52d296e42e5c56efd8@haskell.org> #9828: genprimopcode: parse error ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by erikd): The file `compiler/stage1/build/primops.txt` is generated using a command like: {{{ gcc -E -P -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header \ -Iincludes/dist-ghcconstants/header -Icompiler/stage1 \ -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' \ > compiler/stage2/build/primops.txt }}} and gcc on this machine is `gcc version 4.9.2 (Debian 4.9.2-2)`. If I use `gcc-4.6` in the command above instead of just `gcc` the build proceeds past this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 05:32:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 05:32:39 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM3ODcwOiBDb21waWxhdGlv4oCLbiBlcnJvcnMg?= =?utf-8?q?break_the_complexity_encapsulat=E2=80=8Bion_on_DSLs=2C?= =?utf-8?q?_impairs_success_in_industry?= In-Reply-To: <048.de52b4bfe321c3b82b9c52c180790492@haskell.org> References: <048.de52b4bfe321c3b82b9c52c180790492@haskell.org> Message-ID: <063.5020b44cba2510683dda6acec4fc53a5@haskell.org> #7870: Compilatio?n errors break the complexity encapsulat?ion on DSLs, impairs success in industry -------------------------------------+------------------------------------- Reporter: agocorona | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Keywords: DSL, Error, (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by baramoglo): * cc: emax@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 07:19:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 07:19:07 -0000 Subject: [GHC] #8560: Derive some generic representation for GADTs In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.dde50872b01041f28a2272ed99dbd82b@haskell.org> #8560: Derive some generic representation for GADTs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.7 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Rocket Science Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): I did look into this before (Chapter 10 of my PhD thesis http://dreixel.net/index.php?content=thesis), and there is a reference implementation for the instant-generics package (https://hackage.haskell.org/package/instant-generics). It could be ported to GHC.Generics, but I never found this approach very elegant. I'm still hoping to be able to look into this again at some point in the future, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 07:22:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 07:22:17 -0000 Subject: [GHC] #9831: the 'impossible' happened : iselExpr64(powerpc) Message-ID: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> #9831: the 'impossible' happened : iselExpr64(powerpc) ----------------------------+---------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- After working around the problem in #9828 I now run into this: {{{ "inplace/bin/ghc-stage1" -static -H64m -O -fasm -keep-tmp-files -Iincludes \ -Iincludes/dist -Iincludes/dist-derivedconstants/header \ -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build \ -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts \ -irts/dist/build -irts/dist/build/autogen -Irts/dist/build \ -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm \ -o rts/dist/build/StgStartup.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20141122 for powerpc-unknown-linux): iselExpr64(powerpc) I64[_c1::P32 + 64] - %MO_UU_Conv_W32_W64((Hp + 4) - I32[_c2::I32]) 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 Nov 24 09:30:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 09:30:19 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.4ab7e226c2fc2237cc7945e56c5bab49@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: task | Milestone: 7.10.1 Priority: lowest | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): No problem, I'm busy at the moment but I'll sort it out in good time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 11:16:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 11:16:23 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.ffefd818b65512472194b7bb78023d2c@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #8977 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:10 thomie]: > Strange. When I run the commands from the description with ghc-7.8.3, cpu goes indeed to 100% and the process never finishes. When I do the same with HEAD, everything works fine. I'm on Ubuntu 14.04 x86_64. Strange. Perhaps I will try again with a freshly checked out tree. I am never sure if the submodules worked out right. But blame that on my lack of git skills. > trommler: do you maybe have a better test for this bug? I use `ghc --version`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 14:52:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 14:52:45 -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.78069a9b2798bb921ac726b8221c987e@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree with monoidal. Would someone like to do that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 14:52:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 14:52:57 -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.77e646d0be1f1861104fd978ad455e01@haskell.org> #7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 15:42:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 15:42:30 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.ddd864f55ef20f0c1821fe4e5921a56b@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonmar * priority: normal => high Comment: Simon M: might you re-instate the previous fix, helpfully identified by Yuras, pending a more glorious resolution. (With a pointer from the fix back to this ticket.) I'll make the priority high, because it seems easy and much better than a runtime crash. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 15:43:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 15:43:21 -0000 Subject: [GHC] #5364: Access RTS flag values from inside Haskell programs In-Reply-To: <045.dac6fe30423f96742744c66f751179f8@haskell.org> References: <045.dac6fe30423f96742744c66f751179f8@haskell.org> Message-ID: <060.6fcae646cce8bc19c04a004f280262da@haskell.org> #5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"1617a10aaa75567b776d4a47200ddaa1267771db/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1617a10aaa75567b776d4a47200ddaa1267771db" accessors to RTS flag values -- #5364 Summary: Implementation of #5364. Mostly boilerplate, reading FILE fields is missing. Test Plan: - Get some feedback on missing parts. (FILE fields) - Get some feedback on module name. - Get some feedback on other things. - Get code reviewed. - Make sure test suite is passing. (I haven't run it myself) Reviewers: hvr, austin, ezyang Reviewed By: ezyang Subscribers: ekmett, simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D306 GHC Trac Issues: #5364 Conflicts: includes/rts/Flags.h }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 15:50:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 15:50:01 -0000 Subject: [GHC] #9830: Standalone-derived Show instance for type constructor has different precedence if orphan instance In-Reply-To: <050.5a294db69b3f4b3a7a91abd307a8c2ef@haskell.org> References: <050.5a294db69b3f4b3a7a91abd307a8c2ef@haskell.org> Message-ID: <065.0901742b71f73165fa89bc3ae5c590fd@haskell.org> #9830: Standalone-derived Show instance for type constructor has different precedence if orphan instance -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > If you are using {{{StandaloneDeriving}}} to derive a {{{Show}}} instance > for a data type with an infix constructor, its precedence will be > different depending on which module the {{{deriving instance ...}}} > declaration is in. For example, with this code: > > {{{#!hs > -- InfixShow.hs > {-# LANGUAGE StandaloneDeriving #-} > module InfixShow where > > infixr 6 :?: > data ADT a b = a :?: b deriving (Eq, Ord, Read) > > deriving instance (Show a, Show b) => Show (ADT a b) > }}} > > {{{#!hs > -- Main.hs > module Main where > > import InfixShow > > main :: IO () > main = do > putStrLn $ "Prec 6: " ++ showsPrec 6 ("test" :?: "show") "" > putStrLn $ "Prec 7: " ++ showsPrec 7 ("test" :?: "show") "" > putStrLn $ "Prec 9: " ++ showsPrec 9 ("test" :?: "show") "" > putStrLn $ "Prec 10: " ++ showsPrec 10 ("test" :?: "show") "" > }}} > > Calling {{{runhaskell Main.hs}}} will produce this output, as expected: > > {{{ > Prec 6: "test" :?: "show" > Prec 7: ("test" :?: "show") > Prec 9: ("test" :?: "show") > Prec 10: ("test" :?: "show") > }}} > > However, if the code is changed so that the {{{deriving instance ...}}} > declaration is in {{{Main.hs}}} instead: > > {{{#!hs > -- InfixShow.hs > module InfixShow where > > infixr 6 :?: > data ADT a b = a :?: b deriving (Eq, Ord, Read) > }}} > > {{{#!hs > -- Main.hs > {-# LANGUAGE StandaloneDeriving #-} > module Main where > > import InfixShow > > deriving instance (Show a, Show b) => Show (ADT a b) > > main :: IO () > main = do > putStrLn $ "Prec 6: " ++ showsPrec 6 ("test" :?: "show") "" > putStrLn $ "Prec 7: " ++ showsPrec 7 ("test" :?: "show") "" > putStrLn $ "Prec 9: " ++ showsPrec 9 ("test" :?: "show") "" > putStrLn $ "Prec 10: " ++ showsPrec 10 ("test" :?: "show") "" > }}} > > Then the output of {{{runhaskell Main.hs}}} is different: > > {{{ > Prec 6: "test" :?: "show" > Prec 7: "test" :?: "show" > Prec 9: "test" :?: "show" > Prec 10: ("test" :?: "show") > }}} > > This seems to indicate that {{{:?:}}} has the default application > precedence (9) instead of the precedence defined in {{{InfixShow}}} (6). New description: If you are using {{{StandaloneDeriving}}} to derive a {{{Show}}} instance for a data type with an infix constructor, its precedence will be different depending on which module the {{{deriving instance ...}}} declaration is in. For example, with this code: {{{#!hs -- InfixShow.hs {-# LANGUAGE StandaloneDeriving #-} module InfixShow where infixr 6 :?: data ADT a b = a :?: b deriving (Eq, Ord, Read) deriving instance (Show a, Show b) => Show (ADT a b) }}} {{{#!hs -- Main.hs module Main where import InfixShow main :: IO () main = do putStrLn $ "Prec 6: " ++ showsPrec 6 ("test" :?: "show") "" putStrLn $ "Prec 7: " ++ showsPrec 7 ("test" :?: "show") "" putStrLn $ "Prec 9: " ++ showsPrec 9 ("test" :?: "show") "" putStrLn $ "Prec 10: " ++ showsPrec 10 ("test" :?: "show") "" }}} Calling {{{runhaskell Main.hs}}} will produce this output, as expected: {{{ Prec 6: "test" :?: "show" Prec 7: ("test" :?: "show") Prec 9: ("test" :?: "show") Prec 10: ("test" :?: "show") }}} However, if the code is changed so that the {{{deriving instance ...}}} declaration is in {{{Main.hs}}} instead: {{{#!hs -- InfixShow.hs module InfixShow where infixr 6 :?: data ADT a b = a :?: b deriving (Eq, Ord, Read) }}} {{{#!hs -- Main.hs {-# LANGUAGE StandaloneDeriving #-} module Main where import InfixShow deriving instance (Show a, Show b) => Show (ADT a b) main :: IO () main = do putStrLn $ "Prec 6: " ++ showsPrec 6 ("test" :?: "show") "" putStrLn $ "Prec 7: " ++ showsPrec 7 ("test" :?: "show") "" putStrLn $ "Prec 9: " ++ showsPrec 9 ("test" :?: "show") "" putStrLn $ "Prec 10: " ++ showsPrec 10 ("test" :?: "show") "" }}} Then the output of {{{runhaskell Main.hs}}} is different: {{{ Prec 6: "test" :?: "show" Prec 7: "test" :?: "show" Prec 9: "test" :?: "show" Prec 10: ("test" :?: "show") }}} This seems to indicate that {{{:?:}}} has the default maximum operator precedence (9) instead of the precedence defined in {{{InfixShow}}} (6). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 16:43:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 16:43:47 -0000 Subject: [GHC] #9826: add Storable Complex and Ratio instance to base library In-Reply-To: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> References: <045.466cea1029ee1192fadf7ab16f0c75c9@haskell.org> Message-ID: <060.65ae2c64b0bcc60dfc49f5534a6c2ff2@haskell.org> #9826: add Storable Complex and Ratio instance to base library -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D519 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 16:50:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 16:50:58 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` Message-ID: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (writeme) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 19:10:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 19:10:37 -0000 Subject: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions In-Reply-To: <043.be417919ffcce10010ccb473704f0755@haskell.org> References: <043.be417919ffcce10010ccb473704f0755@haskell.org> Message-ID: <058.60ef7c289bb3e6c3a6f3ba88a89eb7dc@haskell.org> #2269: Word type to Double or Float conversions are slower than Int conversions -------------------------------------+------------------------------------- Reporter: dons | Owner: dons@? Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: rules, Resolution: | performance, double Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Primops for word2Double and word2Float were added 2 years ago. commit 2e8c769422740c001e0a247bfec61d4f78598582 {{{ Author: Johan Tibell <> Date: Wed Dec 5 19:08:48 2012 -0800 Implement word2Float# and word2Double# }}} commit cd01e48fbc548ff8d81ab547108bfdde8a113cd7 {{{ Author: Johan Tibell <> Date: Thu Dec 13 12:03:40 2012 -0800 Add test for word2Double# and word2Float# }}} commit a18cf9cbdfec08732f5b7e0c886a5d899a6a5998 {{{ Author: Johan Tibell <> Date: Thu Dec 13 14:49:58 2012 -0800 Add fromIntegral/Word->Double and fromIntegral/Word-Float rules }}} commit 8cd4ced57dccc1f4f54d242982209ec61e145700 {{{ Author: Johan Tibell <> Date: Tue Dec 18 14:40:02 2012 +0100 perf test for Word->Float/Double conversion }}} commit 6d5f25f5e0b33173fb2e7983cab40808c723f220 {{{ Author: Geoffrey Mainland <> Date: Thu Jan 3 16:59:03 2013 +0000 Fix LLVM code generated for word2Float# and word2Double#. }}} commit 744035fdd4b882c17ef7c6e4439b9e7099e7ec3d {{{ Author: Johan Tibell <> Date: Mon Jan 7 21:35:07 2013 -0800 Fix Word2Float# test on 32-bit }}} The resulting core of the example from the description now looks the same for `Word->Double` as for `Int->Double`. {{{ $ cabal install vector $ cat test.hs {-# LANGUAGE CPP #-} import Data.Vector as V import Data.Word main = print . V.sum #ifdef WORD . V.map (fromIntegral::Word->Double) #else . V.map (fromIntegral::Int->Double) #endif $ V.enumFromTo 0 100000000 $ ghc -ddump-simpl -dsuppress-all -O2 -fforce-recomp -DWORD test.hs -o testWord ... main_$s$wfoldlM'_loop main_$s$wfoldlM'_loop = \ sc_s5G6 sc1_s5G7 -> case tagToEnum# (leWord# sc1_s5G7 (__word 100000000)) of _ { False -> sc_s5G6; True -> main_$s$wfoldlM'_loop (+## sc_s5G6 (word2Double# sc1_s5G7)) (plusWord# sc1_s5G7 (__word 1)) } ... $ ghc -ddump-simpl -dsuppress-all -O2 -fforce-recomp -DINT test.hs -o testInt ... main_$s$wfoldlM'_loop main_$s$wfoldlM'_loop = \ sc_s5GQ sc1_s5GR -> case tagToEnum# (<=# sc1_s5GR 100000000) of _ { False -> sc_s5GQ; True -> main_$s$wfoldlM'_loop (+## sc_s5GQ (int2Double# sc1_s5GR)) (+# sc1_s5GR 1) } }}} But `testWord` is still 3 times slower than `testInt`. {{{ $ time ./testWord 5.00000005e15 real 0m0.579s user 0m0.575s sys 0m0.003s $ time ./testInt 5.00000005e15 real 0m0.196s user 0m0.191s sys 0m0.004s }}} As I can not easily explain this difference, I'll leave this ticket open for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 19:12:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 19:12:41 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.b1747059ab876874fdfb8f5478ae87a6@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #8977 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:11 trommler]: > Replying to [comment:10 thomie]: > > Strange. When I run the commands from the description with ghc-7.8.3, cpu goes indeed to 100% and the process never finishes. When I do the same with HEAD, everything works fine. I'm on Ubuntu 14.04 x86_64. > Strange. Perhaps I will try again with a freshly checked out tree. I am never sure if the submodules worked out right. But blame that on my lack of git skills. On a fresh clone of HEAD at 41c3545 I still see the issue on openSUSE 13.2 i586. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 19:28:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 19:28:57 -0000 Subject: [GHC] #9831: the 'impossible' happened : iselExpr64(powerpc) In-Reply-To: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> References: <044.1090bf2d6b74a28254c5352399819de1@haskell.org> Message-ID: <059.a8bf189630b1128c2558133805b2bfa8@haskell.org> #9831: the 'impossible' happened : iselExpr64(powerpc) ----------------------------------------------+--------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by erikd): * owner: => erikd Comment: Working on a fix for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 19:51:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 19:51:18 -0000 Subject: [GHC] #7460: Double literals generated bad core In-Reply-To: <044.ed196d4ab32273e6f17e019e39460f29@haskell.org> References: <044.ed196d4ab32273e6f17e019e39460f29@haskell.org> Message-ID: <059.bfeea30a3a4cbf19cbdd40daf33e7a83@haskell.org> #7460: Double literals generated bad core -------------------------------------+------------------------------------- Reporter: tibbe | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: The word2Float and word2Double primops were added, which solved this issue. The output of `ghc-7.6.3 -ddump-simpl -O2 test.hs` contained calls to `doubleFromInteger`, but the same command using `ghc-7.8.3` does not (which is good). Other things must have changed as well, because the code is about twice as fast with 7.8.3, while comment:8 talked about a difference of only 20%. commit 2e8c769422740c001e0a247bfec61d4f78598582 {{{ Author: Johan Tibell <> Date: Wed Dec 5 19:08:48 2012 -0800 Implement word2Float# and word2Double# }}} commit cd01e48fbc548ff8d81ab547108bfdde8a113cd7 {{{ Author: Johan Tibell <> Date: Thu Dec 13 12:03:40 2012 -0800 Add test for word2Double# and word2Float# }}} commit a18cf9cbdfec08732f5b7e0c886a5d899a6a5998 {{{ Author: Johan Tibell <> Date: Thu Dec 13 14:49:58 2012 -0800 Add fromIntegral/Word->Double and fromIntegral/Word-Float rules }}} commit 8cd4ced57dccc1f4f54d242982209ec61e145700 {{{ Author: Johan Tibell <> Date: Tue Dec 18 14:40:02 2012 +0100 perf test for Word->Float/Double conversion }}} commit 6d5f25f5e0b33173fb2e7983cab40808c723f220 {{{ Author: Geoffrey Mainland <> Date: Thu Jan 3 16:59:03 2013 +0000 Fix LLVM code generated for word2Float# and word2Double#. }}} commit 744035fdd4b882c17ef7c6e4439b9e7099e7ec3d {{{ Author: Johan Tibell <> Date: Mon Jan 7 21:35:07 2013 -0800 Fix Word2Float# test on 32-bit }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:08:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:08:24 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.df72c53db9a79762d2dc9da093d9ceb6@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): OK -- so it seems you want to be able to fuzz the `*`/`Constraint` distinction. That is, for example, make explicit dictionaries of `Show` and pass them as parameters to functions with a declared `Show` constraint. Another way to think about this is that you want the ability to define local instances, much like what is done in that blog post. The problem here is that local instances threaten coherence properties. Local instances are really useful, but I think a fair amount of design work needs to be done to integrate local instances with Haskell. Or, simply to automate building `Def` instances, I would suggest Template Haskell. Without a general plan toward local instances, it seems too specific to bake in deriving `Def` instances into GHC, when it can easily be done with TH. [https://groups.google.com/forum/#!msg/haskell- cafe/JR8qd6RBKW4/xDcdtmuE9gsJ This haskell-cafe thread] may be of interest. It explores some of this design space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:24:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:24:46 -0000 Subject: [GHC] #7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile In-Reply-To: <050.60faff6d4b249b981494dc420c65e26f@haskell.org> References: <050.60faff6d4b249b981494dc420c65e26f@haskell.org> Message-ID: <065.270cd651a0de86244370af7696f73241@haskell.org> #7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile -------------------------------------+------------------------------------- Reporter: | Owner: orenbenkiki | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Profiling | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: I had a look at the files in the attached zip file. There is a `RUN` script with hard coded directory paths that don't exist on my system, two `.hscpp` that import a module called `Haski` that I can't find on hackage, and a giant `c` that is supposedly giving you troubles. As it stands, your problem is rather hard to reproduce. Could you please make a smaller, self-contained, example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:25:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:25:51 -0000 Subject: [GHC] #7643: Kind application error In-Reply-To: <048.a03d3c055f589ce6d978bf10fc16a0fa@haskell.org> References: <048.a03d3c055f589ce6d978bf10fc16a0fa@haskell.org> Message-ID: <063.cc2bcdb6bbeba265709d633893b8a84b@haskell.org> #7643: Kind application error -------------------------------------+------------------------------------- Reporter: gmainland | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7354, #8355 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"63d2adaef999258d874a760591e9c9ec3d75aeaf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="63d2adaef999258d874a760591e9c9ec3d75aeaf" Test #7643 in typecheck/should_compile/T7643. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:25:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:25:51 -0000 Subject: [GHC] #8044: "Inaccessible code" error reported in wrong place In-Reply-To: <047.ca5edea8fc93ab55042ca6cee2bd6cb8@haskell.org> References: <047.ca5edea8fc93ab55042ca6cee2bd6cb8@haskell.org> Message-ID: <062.2b77f0d21485b99a68bcd58d9371e2d0@haskell.org> #8044: "Inaccessible code" error reported in wrong place -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 (Type checker) | Keywords: GADTs Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"8459404b6431e44669f8732b6787c7d6b67b984b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8459404b6431e44669f8732b6787c7d6b67b984b" Test #8044 in typecheck/should_fail/T8044 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:25:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:25:51 -0000 Subject: [GHC] #8031: Template Haskell gets confused with kind variables introduced in separate foralls In-Reply-To: <047.defe71e5e3f09763c5eefe74f7326e80@haskell.org> References: <047.defe71e5e3f09763c5eefe74f7326e80@haskell.org> Message-ID: <062.9da52d5bf243569a59f5f3d8b9a40130@haskell.org> #8031: Template Haskell gets confused with kind variables introduced in separate foralls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: PolyKinds Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5c3541548e441456ca6a0dd62caf8acd7fc5cf33/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5c3541548e441456ca6a0dd62caf8acd7fc5cf33" Test #8031 in th/T8031 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:26:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:26:38 -0000 Subject: [GHC] #7643: Kind application error In-Reply-To: <048.a03d3c055f589ce6d978bf10fc16a0fa@haskell.org> References: <048.a03d3c055f589ce6d978bf10fc16a0fa@haskell.org> Message-ID: <063.3d805ed210dcd3904a65904d5ab67ebe@haskell.org> #7643: Kind application error -------------------------------------+------------------------------------- Reporter: gmainland | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7354, #8355 None/Unknown | Test Case: | typecheck/should_compile/T7643 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_compile/T7643 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:27:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:27:02 -0000 Subject: [GHC] #8044: "Inaccessible code" error reported in wrong place In-Reply-To: <047.ca5edea8fc93ab55042ca6cee2bd6cb8@haskell.org> References: <047.ca5edea8fc93ab55042ca6cee2bd6cb8@haskell.org> Message-ID: <062.bf929a00b61e137bf6d0c082f37ef9e9@haskell.org> #8044: "Inaccessible code" error reported in wrong place -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 (Type checker) | Keywords: GADTs Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_fail/T8044 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_fail/T8044 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:27:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:27:17 -0000 Subject: [GHC] #8031: Template Haskell gets confused with kind variables introduced in separate foralls In-Reply-To: <047.defe71e5e3f09763c5eefe74f7326e80@haskell.org> References: <047.defe71e5e3f09763c5eefe74f7326e80@haskell.org> Message-ID: <062.0e345e540a24ba51cef185d7187b3102@haskell.org> #8031: Template Haskell gets confused with kind variables introduced in separate foralls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: PolyKinds Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T8031 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => th/T8031 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:32:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:32:16 -0000 Subject: [GHC] #7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile In-Reply-To: <050.60faff6d4b249b981494dc420c65e26f@haskell.org> References: <050.60faff6d4b249b981494dc420c65e26f@haskell.org> Message-ID: <065.176e66547c84b7f4e31204f608c28585@haskell.org> #7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile -------------------------------------+------------------------------------- Reporter: | Owner: orenbenkiki | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Profiling | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by orenbenkiki): Well... it has been a while since I submitted the original report and my code base has mutated and grown a lot since then. It is a pretty large project and contains information I can't release out of my company... The question seems to be why the generated code builds the linked list dynamically rather than as static initializers, this "should" be unrelated to the inputs... right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:46:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:46:10 -0000 Subject: [GHC] #7437: peculiar behaviour with default instances and type variables In-Reply-To: <042.0fb474a7e7daa2f1660f34dd883e2b94@haskell.org> References: <042.0fb474a7e7daa2f1660f34dd883e2b94@haskell.org> Message-ID: <057.72897a0291e27ff33eada92c5ffc8147@haskell.org> #7437: peculiar behaviour with default instances and type variables -------------------------------------+------------------------------------- Reporter: bos | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * component: Compiler => Compiler (Type checker) Comment: Uncommenting the `FlexibleInstances` pragma does not have an effect on the error message with ghc HEAD (or ghc-7.8.3), and the message also seems much improved: {{{ $ cat test.hs {-# LANGUAGE DefaultSignatures, FlexibleContexts, DeriveGeneric #-} {-# LANGUAGE FlexibleInstances #-} module Whee where ... $ ghc-7.9.20141121 test.hs [1 of 1] Compiling Whee ( test.hs, test.o ) test.hs:12:1: Could not deduce (Put a0) from the context (Put a, Generic t, GPut (Rep t)) bound by the type signature for put :: (Put a, Generic t, GPut (Rep t)) => t -> [()] at test.hs:(12,1)-(17,21) The type variable ?a0? is ambiguous In the ambiguity check for the type signature for ?put?: put :: forall a. Put a => forall t. (Generic t, GPut (Rep t)) => t -> [()] To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: put :: a -> [()] In the class declaration for ?Put? }}} Does that means this issue is resolved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 20:49:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 20:49:31 -0000 Subject: [GHC] #7430: GHC API reports CPP errors in confusing ways In-Reply-To: <054.b42c4bcfb151eb512103f6c292b13b85@haskell.org> References: <054.b42c4bcfb151eb512103f6c292b13b85@haskell.org> Message-ID: <069.f9e7df93bc3786b0a3ed974fa9c57ac5@haskell.org> #7430: GHC API reports CPP errors in confusing ways -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Confirmed with 7.8.3. Unfortunately the example doesn't compile with `ghc-7.9.20141121`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 21:58:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 21:58:27 -0000 Subject: [GHC] #7398: RULES don't apply to a newtype constructor In-Reply-To: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> References: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> Message-ID: <061.43c7cdcd3a41f6e5739355712d8be9c3@haskell.org> #7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): GHC 7.8.3 now shows two warnings: {{{ $ ghc-7.8.3 -fforce-recomp -O2 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) D.hs:9:11: Warning: Rule "rule Foo" may never fire because ?Main.Foo? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?Main.Foo? D.hs:10:11: Warning: Rule "rule foo" may never fire because ?foo? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?foo? Linking D ... }}} GHC HEAD shows a different warning: {{{ $ ghc-7.9.20141121 -O2 -fforce-recomp D.hs [1 of 1] Compiling Main ( D.hs, D.o ) D.hs:9:11: Warning: RULE left-hand side too complicated to desugar Optimised lhs: v `cast` (Sym (Main.NTCo:Foo[0] _R) :: a ~R# Foo a) Orig lhs: Main.Foo @ a v D.hs:10:11: Warning: Rule "rule foo" may never fire because ?foo? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?foo? }}} If the warning `RULE left-hand side too complicated to desugar` is correct, we should add a test for it (there currently aren't any). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 21:59:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 21:59:47 -0000 Subject: [GHC] #7398: RULES don't apply to a newtype constructor In-Reply-To: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> References: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> Message-ID: <061.15c3d49c8d9c319e266d183293adbe2c@haskell.org> #7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: #6082 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #6082 Comment: The warnings were added in commit 79062a8a0e9168b7f925c05699c30333563a9303: {{{ Author: Simon Peyton Jones <> Date: Mon Jul 23 09:17:09 2012 +0100 Make the desugarer warn about RULES that may not fire This warning was suggested by Trac #6082, where we had a library RULE that failed to fire because its function was inlined too soon. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 22:12:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 22:12:51 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.bdc689dda16f9bddcdf792affa6a4da7@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: gcampax Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D524 | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: simonmar => gcampax * differential: => D524 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 22:26:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 22:26:11 -0000 Subject: [GHC] #7389: can't link postgresql-libpq on windows In-Reply-To: <047.308461056cfcd94cf59d943fa58b1d9d@haskell.org> References: <047.308461056cfcd94cf59d943fa58b1d9d@haskell.org> Message-ID: <062.97bd2098716cb426b81ce072599f1bb0@haskell.org> #7389: can't link postgresql-libpq on windows ----------------------------------------+---------------------------------- Reporter: eflister | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: 3658, 5987 Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Changes (by thomie): * cc: hvr (added) * blockedby: 3658 => 3658, 5987 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 22:34:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 22:34:36 -0000 Subject: [GHC] #7955: CApiFFI doesn't produce wrappers for #defined values in GHCi In-Reply-To: <045.c0c90a4831a6cefb78b1fd47bb8ea416@haskell.org> References: <045.c0c90a4831a6cefb78b1fd47bb8ea416@haskell.org> Message-ID: <060.b8c28e4592db14e1a6fa505e1b578079@haskell.org> #7955: CApiFFI doesn't produce wrappers for #defined values in GHCi -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.6.3 Resolution: duplicate | Keywords: ghci, capi Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: #7388 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * difficulty: => Unknown * status: new => closed * resolution: => duplicate * related: => #7388 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 22:35:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 22:35:16 -0000 Subject: [GHC] #7388: CAPI doesn't work with ghci In-Reply-To: <044.45a130d5455804a7b37a7d8862986ddd@haskell.org> References: <044.45a130d5455804a7b37a7d8862986ddd@haskell.org> Message-ID: <059.f0027cb495427f5fa6d1e9b85e2f8084@haskell.org> #7388: CAPI doesn't work with ghci -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: T4012 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) Comment: See also #7955. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 22:48:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 22:48:59 -0000 Subject: [GHC] #7380: Panic: mkNoTick: Breakpoint loading modules with -O2 via API In-Reply-To: <059.5c8d434585185e898384f0ffd9f7cbd9@haskell.org> References: <059.5c8d434585185e898384f0ffd9f7cbd9@haskell.org> Message-ID: <074.e013e1231741273ce8d41b1d63e82366@haskell.org> #7380: Panic: mkNoTick: Breakpoint loading modules with -O2 via API -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Windows => Unknown/Multiple * architecture: ia64 => Unknown/Multiple Comment: I can reproduce this bug on Linux. Change the let binding `fp` in `Main.hs` to the path of a file that contains: {{{ main::IO() main = print "Hello Fay" }}} Then: {{{ $ cabal install ghc-paths $ ghc-7.9.20141121 -package ghc Main.hs $ ./Main Main: Main: panic! (the 'impossible' happened) (GHC version 7.9.20141121 for x86_64-unknown-linux): mkNoCount: Breakpoint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 23:17:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 23:17:33 -0000 Subject: [GHC] #7337: GHC does not generate great code for bit-level rotation In-Reply-To: <042.1bdaae6f89f84d88685747f45c6e6712@haskell.org> References: <042.1bdaae6f89f84d88685747f45c6e6712@haskell.org> Message-ID: <057.ee873eb52a2a0567cec071835d824b0e@haskell.org> #7337: GHC does not generate great code for bit-level rotation -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: (NCG) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: Compiler => Compiler (NCG) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 23:18:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 23:18:56 -0000 Subject: [GHC] #7335: Need for extra warning pragma for accidental pattern matching in do blocks In-Reply-To: <045.ae08702e11f5091666632c3d21fbbf7d@haskell.org> References: <045.ae08702e11f5091666632c3d21fbbf7d@haskell.org> Message-ID: <060.ac1688a50f9c8234b0dcae41d47d65ea@haskell.org> #7335: Need for extra warning pragma for accidental pattern matching in do blocks -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 23:34:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 23:34:10 -0000 Subject: [GHC] #7305: T5975a is broken on Windows In-Reply-To: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> References: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> Message-ID: <062.f7558914b894929c978eb3f2683c89e5@haskell.org> #7305: T5975a is broken on Windows -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: gintas (added) * os: Unknown/Multiple => Windows Comment: This is still an issue according to this email: https://www.haskell.org/pipermail/ghc-devs/2014-November/007146.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 23:52:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 23:52:39 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info In-Reply-To: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> References: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> Message-ID: <060.d4a9821463a7f7dd4a19b2f28432a446@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by monoidal): I reduced the panic to this (to reproduce just run `ghci Bug9574`). It makes 7.9 panic but not 7.8, likely by accident though. {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, ScopedTypeVariables, GADTs, RankNTypes #-} module Bug9574 where data KProxy (t :: *) = KProxy data Proxy p class Funct f where type Codomain f :: * instance Funct ('KProxy :: KProxy o) where type Codomain 'KProxy = NatTr (Proxy :: o -> *) data NatTr (c :: o -> *) where M :: (forall (a :: o). Proxy a) -> NatTr (c :: o -> *) p :: forall (c :: o -> *). NatTr c p = M t where M t = undefined :: Codomain ('KProxy :: KProxy o) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 24 23:58:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Nov 2014 23:58:13 -0000 Subject: [GHC] #8338: Incoherent instances without -XIncoherentInstances In-Reply-To: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> References: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> Message-ID: <062.7f17ba591661fbf3c5b56f48217f5006@haskell.org> #8338: Incoherent instances without -XIncoherentInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #2356 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Only looking at the title, is this a duplicate of #7296? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 00:01:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 00:01:02 -0000 Subject: [GHC] #7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances` In-Reply-To: <045.c1f8320cef92e26e9e6eb421535d1090@haskell.org> References: <045.c1f8320cef92e26e9e6eb421535d1090@haskell.org> Message-ID: <060.1cbb8dada7bf6cbafc849e2aa180a386@haskell.org> #7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances` -------------------------------------+------------------------------------- Reporter: maeder | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #8338 accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8338 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 01:27:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 01:27:01 -0000 Subject: [GHC] #7277: Recompilation check fails for TH unless functions are inlined In-Reply-To: <050.603d1a84b9f7903399d4601701fdbcaa@haskell.org> References: <050.603d1a84b9f7903399d4601701fdbcaa@haskell.org> Message-ID: <065.b1c51537f45b3abf42759be6858de403@haskell.org> #7277: Recompilation check fails for TH unless functions are inlined -------------------------------------+------------------------------------- Reporter: | Owner: orenbenkiki | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 481 Type of failure: Incorrect | result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): I'm able to reproduce this with 7.8.3, by first doing `cabal install test- framework test-framework-hunit test-framework-th` and then running the `RUNME` script inside the tar file from comment:1. The fourth and final test should be failing instead of passing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 02:11:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 02:11:28 -0000 Subject: [GHC] #7243: regression: acceptable foreign result types In-Reply-To: <044.20527182530838d815e1a65c339ea3b9@haskell.org> References: <044.20527182530838d815e1a65c339ea3b9@haskell.org> Message-ID: <059.11d668d301bda963897649837a405636@haskell.org> #7243: regression: acceptable foreign result types -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (FFI) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): In commit 92587bfefea2b78f89bcdad27e0da5711463fd1b: {{{ Author: Simon Peyton Jones <> Date: Fri Jul 25 16:22:21 2014 +0100 Refactor FFI error messages This patch was provoked by Trac #5610, which I finally got a moment to look at. In the end I added a new data type ErrUtils.Validity, data Validity = IsValid -- Everything is fine | NotValid MsgDoc -- A problem, and some indication of why with some suitable combinators, and used it where appropriate (which touches quite a few modules). The main payoff is that error messages improve for FFI type validation. }}} The error message is now: {{{ $ ghc-7.9.20141121 test.hs [1 of 1] Compiling Foo ( test.hs, test.o ) test.hs:3:1: Unacceptable type in foreign declaration: One argument expected When checking declaration: foreign import ccall safe "wrapper" foo :: IO (FunPtr ()) }}} Only a regression test is missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 02:13:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 02:13:49 -0000 Subject: [GHC] #9392: "\n" is displayed weirdly in error messages In-Reply-To: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> References: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> Message-ID: <066.502b27424a10f8dba982396084285a90@haskell.org> #9392: "\n" is displayed weirdly in error messages -------------------------------------+------------------------------------- Reporter: | Owner: jlengyel Artyom.Kazak | Status: new Type: bug | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #9681 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jlengyel): * owner: => jlengyel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 02:55:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 02:55:02 -0000 Subject: [GHC] #7190: GHC's -fprof-auto does not work with LINE pragmas In-Reply-To: <049.b7337da5880f7d950e41894a88c70fc8@haskell.org> References: <049.b7337da5880f7d950e41894a88c70fc8@haskell.org> Message-ID: <064.fbe0c329f40b9e6f692483fe3191aa67@haskell.org> #7190: GHC's -fprof-auto does not work with LINE pragmas -------------------------------------+------------------------------------- Reporter: timthelion | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Profiling | Version: 7.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This seems to be fixed in or before the 7.8.1 release. The profiling report for `profpragma.hs` now does have an entry for the function `main`. A regression should be added, then this ticket can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 03:04:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 03:04:15 -0000 Subject: [GHC] #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles In-Reply-To: <045.7e6a94d263b25a206477fac55bd4f0ca@haskell.org> References: <045.7e6a94d263b25a206477fac55bd4f0ca@haskell.org> Message-ID: <060.1cc349fafc2ee470a3fa012da95287cc@haskell.org> #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1-rc1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 03:13:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 03:13:16 -0000 Subject: [GHC] #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances In-Reply-To: <047.146348de4d2b18e1ad0360b7562542c2@haskell.org> References: <047.146348de4d2b18e1ad0360b7562542c2@haskell.org> Message-ID: <062.8e67b15936998d24e6052b9bf56b10c1@haskell.org> #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7296 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #7296 Comment: This is by design, for better or worse. See #7296 for an explanation. I'm sure the fix -- that is, redesign -- for that ticket and this one will be the same, but I think it's worth leaving both tickets open, as the examples are slightly different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 03:14:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 03:14:10 -0000 Subject: [GHC] #7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances` In-Reply-To: <045.c1f8320cef92e26e9e6eb421535d1090@haskell.org> References: <045.c1f8320cef92e26e9e6eb421535d1090@haskell.org> Message-ID: <060.d6f455c4627fb5e4c5080df86eb7e812@haskell.org> #7296: ghc-7 assumes incoherent instances without requiring language `IncoherentInstances` -------------------------------------+------------------------------------- Reporter: maeder | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #9820 accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: #8338 => #9820 Comment: See #9820 for another example of how this might happen. (I don't believe #8338 is related to this ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 03:15:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 03:15:43 -0000 Subject: [GHC] #8338: Incoherent instances without -XIncoherentInstances In-Reply-To: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> References: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> Message-ID: <062.9f519124aadc251cbc8410bf7e806ba6@haskell.org> #8338: Incoherent instances without -XIncoherentInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #2356 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): No, #7296 is unrelated. This ticket is all about GHC's lazy overlap check, while #7296 is a puzzling behavior introduced by considering overlap differently when type-checking an instance method. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 03:22:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 03:22:01 -0000 Subject: [GHC] #7141: Inlining the single method of a class can shadow rules In-Reply-To: <049.83c368d6a311c5a05d4c15da56fc3e46@haskell.org> References: <049.83c368d6a311c5a05d4c15da56fc3e46@haskell.org> Message-ID: <064.cb127932eab2f90c0dec4c7aa9558675@haskell.org> #7141: Inlining the single method of a class can shadow rules -------------------------------------+------------------------------------- Reporter: pcapriotti | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.4.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 03:23:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 03:23:18 -0000 Subject: [GHC] #9392: "\n" is displayed weirdly in error messages In-Reply-To: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> References: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> Message-ID: <066.c8fcfb0880f50ec1b99c47ff31f68e82@haskell.org> #9392: "\n" is displayed weirdly in error messages -------------------------------------+------------------------------------- Reporter: | Owner: Artyom.Kazak | Status: new Type: bug | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #9681 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jlengyel): * owner: jlengyel => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 03:27:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 03:27:27 -0000 Subject: [GHC] #7133: GHCi: strange behaviour after CTRL-C, followed by 'hPutChar: resource vanished (Broken Pipe)' when quitting In-Reply-To: <053.2b0536115707fa6b35bc3c14838eb88c@haskell.org> References: <053.2b0536115707fa6b35bc3c14838eb88c@haskell.org> Message-ID: <068.09eb79fd5c4e932d114ad0f7b0dfac58@haskell.org> #7133: GHCi: strange behaviour after CTRL-C, followed by 'hPutChar: resource vanished (Broken Pipe)' when quitting -------------------------------------+------------------------------------- Reporter: | Owner: tibbe DuncanMortimer | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * status: new => infoneeded Comment: Can anyone on Mac OS X reproduce this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 03:57:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 03:57:22 -0000 Subject: [GHC] #7133: GHCi: strange behaviour after CTRL-C, followed by 'hPutChar: resource vanished (Broken Pipe)' when quitting In-Reply-To: <053.2b0536115707fa6b35bc3c14838eb88c@haskell.org> References: <053.2b0536115707fa6b35bc3c14838eb88c@haskell.org> Message-ID: <068.d2db8bda5d1208c68ed7e1206772102e@haskell.org> #7133: GHCi: strange behaviour after CTRL-C, followed by 'hPutChar: resource vanished (Broken Pipe)' when quitting -------------------------------------+------------------------------------- Reporter: | Owner: tibbe DuncanMortimer | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I can't reproduce this in 7.8.3 on OS X 10.9 with the 10.9 terminal app (unless i'm interpreting the directions wrong) What version of OS X and terminal was this bug originaly reported for? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 04:16:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 04:16:16 -0000 Subject: [GHC] #7109: Inlining depends on datatype size, even with INLINE pragmas In-Reply-To: <046.d7688d63b8d11652e4d6ca8d86579926@haskell.org> References: <046.d7688d63b8d11652e4d6ca8d86579926@haskell.org> Message-ID: <061.7a91f65f0ee3bc921b0e323312ddfd05@haskell.org> #7109: Inlining depends on datatype size, even with INLINE pragmas -------------------------------------+------------------------------------- Reporter: dreixel | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: The function `$fGEqLogic_$cgeq` from the output of `ghc -fforce-recomp -ddump-simpl -dsuppress-all -O1 Bug3.hs` with ghc-7.9.20141121 (HEAD): {{{ Rec { $fGEqLogic_$cgeq $fGEqLogic_$cgeq = \ x_aYx y_aYy -> let { $j_s1Y5 $j_s1Y5 = \ a9_a1kB -> case y_aYy of _ { __DEFAULT -> False; Not g1_aBh_a1kM -> case a9_a1kB of _ { L1 a10_a1kz -> $fGEqLogic_$cgeq (a10_a1kz `cast` ...) g1_aBh_a1kM; R1 a10_X1o5 -> False }; And g1_aBi_a1kN g2_aBj_a1kO -> case a9_a1kB of _ { L1 a10_a1kz -> False; R1 a10_X1o5 -> case a10_X1o5 `cast` ... of _ { :*: a11_a171 b1_a172 -> case $fGEqLogic_$cgeq (a11_a171 `cast` ...) g1_aBi_a1kN of _ { False -> False; True -> $fGEqLogic_$cgeq (b1_a172 `cast` ...) g2_aBj_a1kO } } } } } in case x_aYx of _ { T -> case y_aYy of _ { T -> True; F -> False; Not g1_aBh_a1kM -> False; And g1_aBi_a1kN g2_aBj_a1kO -> False }; F -> case y_aYy of _ { __DEFAULT -> False; F -> True }; Not g1_aBh_a1kM -> $j_s1Y5 (L1 (g1_aBh_a1kM `cast` ...)); And g1_aBi_a1kN g2_aBj_a1kO -> $j_s1Y5 (R1 ((:*: (g1_aBi_a1kN `cast` ...) (g2_aBj_a1kO `cast` ...)) `cast` ...)) } end Rec } }}} Pedro: is that sufficiently small, or do you still think there is a bug somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 04:50:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 04:50:54 -0000 Subject: [GHC] #7114: Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1 In-Reply-To: <046.fae9ca2bbb58d7bf9387efb9e72b692a@haskell.org> References: <046.fae9ca2bbb58d7bf9387efb9e72b692a@haskell.org> Message-ID: <061.3f04f54d0e65411c3c7c6a23422f90bb@haskell.org> #7114: Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1 -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This issue is not resolved yet. Relevant part of the output of `ghc-7.9.20141121 -fforce-recomp -ddump-simpl -O1 Code3.hs` still has the same structure (to reproduce, search for last `Rec` in the output): {{{#!hs lvl_r1aH :: [List] [GblId, Caf=NoCafRefs, Str=DmdType] lvl_r1aH = GHC.Types.: @ List Code2.Nil (GHC.Types.[] @ List) Rec { Code2.$senum'5 :: [K1 List] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] Code2.$senum'5 = map @ List @ (K1 List) (Code2.K1 @ List) Code2.$fGEnumList_$cgenum lvl1_r1aI :: Int -> [List] [GblId, Arity=1, Str=DmdType] lvl1_r1aI = \ (x_XNx :: Int) -> map @ (K1 List) @ List (\ (x1_XOq :: K1 List) -> case x1_XOq of _ [Occ=Dead] { K1 b_axA -> Code2.Cons x_XNx b_axA }) Code2.$senum'5 lvl2_r1aJ :: [[List]] [GblId, Str=DmdType] lvl2_r1aJ = map @ Int @ [List] lvl1_r1aI Code2.$fGEnumInt_$cgenum lvl3_r1aK :: [List] [GblId, Str=DmdType] lvl3_r1aK = diag @ List lvl2_r1aJ Code2.$fGEnumList_$cgenum [Occ=LoopBreaker] :: [List] [GblId, Str=DmdType] Code2.$fGEnumList_$cgenum = ||| @ List lvl_r1aH lvl3_r1aK end Rec } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 09:16:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 09:16:39 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.e63d147e0a9c65f733694b7aed9d0580@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Difficult (2-5 None/Unknown | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => perl * difficulty: Unknown => Difficult (2-5 days) * component: Compiler => Driver * priority: normal => high Old description: > (writeme) New description: The problem: `ghc-split` is a ~280 SLOC (literate) Perl script and it's needed at runtime by GHC. Which means that we depend on a Perl interpreter, and since Windows usually doesn't have one installed by default, we need to bundle a Perl interpreter w/ the GHC binary Windows distribution for convenience. Obvious solutions: 1. Rewrite `ghc-split` tool in Haskell, or 2. Merge `ghc-split` functionality into GHC proper -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 11:53:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 11:53:45 -0000 Subject: [GHC] #7028: incorrect link paths for in mac os x after install In-Reply-To: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> References: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> Message-ID: <065.e9711c1cc2bf4027d94c364302557090@haskell.org> #7028: incorrect link paths for in mac os x after install -------------------------------------+------------------------------------- Reporter: | Owner: leroux andykitchen | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Build | Keywords: System | Architecture: x86_64 (amd64) Resolution: worksforme | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Installing | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Please re-open if you're still having problems with version 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 11:56:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 11:56:42 -0000 Subject: [GHC] #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong Message-ID: <051.4f374768f35d40920f184256a5b1e2ba@haskell.org> #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- With `InstanceSigs` and `PolyKinds` enabled and the following type with kind `? -> *`: {{{#!hs data NullableInterp a = NullI Bool }}} I want to make it an instance of `Alternative` and I decide to supply a signature for `empty`: {{{#!hs instance Alternative NullableInterp where empty :: NullableInterp a empty = undefined (<|>) = undefined }}} but GHCi complains with the following error: {{{#!hs % ghci -ignore-dot-ghci error.hs GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( error.hs, interpreted ) error.hs:14:12: Method signature does not match class; it should be empty :: forall a. NullableInterp a In the instance declaration for ?Alternative NullableInterp? Failed, modules loaded: none. Prelude> }}} Trying GHCi's suggestion (with appropriate extensions) doesn't help and I have to write `empty :: NullableInterp (a :: *)` for it to work. I'm not sure which behaviour is the right one but either it should have compiled or GHCi's suggestion should be `empty :: forall a. NullableInterp (a :: *)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 13:43:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 13:43:02 -0000 Subject: [GHC] #7109: Inlining depends on datatype size, even with INLINE pragmas In-Reply-To: <046.d7688d63b8d11652e4d6ca8d86579926@haskell.org> References: <046.d7688d63b8d11652e4d6ca8d86579926@haskell.org> Message-ID: <061.b3233e49e244b3533f9ddf558ebf67ff@haskell.org> #7109: Inlining depends on datatype size, even with INLINE pragmas -------------------------------------+------------------------------------- Reporter: dreixel | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:4 thomie]: > Pedro: is that sufficiently small, or do you still think there is a bug somewhere? I think there's still a problem. Let's look at the code for `Bug2.hs`, which simply has one fewer constructor: {{{ $fGEqLogic_$cgeq $fGEqLogic_$cgeq = \ x_aYs y_aYt -> case x_aYs of _ { T -> case y_aYt of _ { T -> True; F -> False; Not g1_aBc_a1kH -> False }; F -> case y_aYt of _ { __DEFAULT -> False; F -> True }; Not g1_aBc_a1kH -> case y_aYt of _ { __DEFAULT -> False; Not g1_aBc1_X1mN -> $fGEqLogic_$cgeq g1_aBc_a1kH g1_aBc1_X1mN } } }}} This looks good. No casts, no `L`/`R`, just a perfectly specialised function. In contrast, `Bug3` (which simply adds one constructor) has generic representation leftovers and casts all over the place. It still feels like something is behaving significantly different just because the datatype got slightly bigger, and I don't know how to tell GHC that it shouldn't be afraid of inlining stuff just because the terms are bigger. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 13:53:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 13:53:14 -0000 Subject: [GHC] #9834: GHC panic when used with deferred type errors Message-ID: <051.4829af2311d69829d3866ca80599e051@haskell.org> #9834: GHC panic when used with deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Linux Keywords: | Type of failure: GHCi crash Architecture: Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Attached code panics when run with `-fdefer-type-errors`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 13:56:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 13:56:46 -0000 Subject: [GHC] #9834: GHC panic when used with deferred type errors In-Reply-To: <051.4829af2311d69829d3866ca80599e051@haskell.org> References: <051.4829af2311d69829d3866ca80599e051@haskell.org> Message-ID: <066.c8fae7abe0b00c12652f9c8c7e2a257c@haskell.org> #9834: GHC panic when used with deferred type errors -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Attached code panics when run with `-fdefer-type-errors`. New description: Attached code panics when run with `-fdefer-type-errors`. '''Edit:''' Code should not type check but it should not cause a panic either :) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 16:22:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 16:22:09 -0000 Subject: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 In-Reply-To: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> References: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> Message-ID: <058.f3deaeaeaa139588a6fadfb3265fa9f8@haskell.org> #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 -------------------------------------+------------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.5 Libraries | Keywords: Mountain Lion Resolution: worksforme | Architecture: x86 Operating System: MacOS X | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * failure: None/Unknown => Building GHC failed * status: infoneeded => closed * resolution: => worksforme Comment: With #9281, `integer-gmp` is obsolete. Please open a new ticket if there are any problems compiling `integer-gmp2` on OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 16:26:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 16:26:58 -0000 Subject: [GHC] #9834: GHC panic when used with deferred type errors In-Reply-To: <051.4829af2311d69829d3866ca80599e051@haskell.org> References: <051.4829af2311d69829d3866ca80599e051@haskell.org> Message-ID: <066.36f199e6b6915f6b77b773808ab2b9a4@haskell.org> #9834: GHC panic when used with deferred type errors -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Works fine in HEAD. Can someone try the 7.8.4 branch? Here are the HEAD error messages. I have not looked at them, but there is no crash. {{{ T9834.hs:24:10: Warning: Couldn't match type ?p? with ?(->) (p a0)? ?p? is a rigid type variable bound by the class declaration for ?ApplicativeFix? at T9834.hs:22:39 Expected type: (forall (q :: * -> *). Applicative q => Comp p q a -> Comp p q a) -> p a Actual type: (forall (q :: * -> *). Applicative q => Nat (Comp p q) (Comp p q)) -> p a0 -> p a0 Relevant bindings include afix :: (forall (q :: * -> *). Applicative q => Comp p q a -> Comp p q a) -> p a (bound at T9834.hs:24:3) In the expression: wrapIdComp In an equation for ?afix?: afix = wrapIdComp T9834.hs:24:10: Warning: Couldn't match type ?a? with ?p a0? ?a? is a rigid type variable bound by the type signature for afix :: (forall (q :: * -> *). Applicative q => Comp p q a -> Comp p q a) -> p a at T9834.hs:23:11 Expected type: (forall (q :: * -> *). Applicative q => Comp p q a -> Comp p q a) -> p a Actual type: (forall (q :: * -> *). Applicative q => Nat (Comp p q) (Comp p q)) -> p a0 -> p a0 Relevant bindings include afix :: (forall (q :: * -> *). Applicative q => Comp p q a -> Comp p q a) -> p a (bound at T9834.hs:24:3) In the expression: wrapIdComp In an equation for ?afix?: afix = wrapIdComp T9834.hs:24:10: Warning: Couldn't match type ?a? with ?a1? ?a? is a rigid type variable bound by the type signature for afix :: (forall (q :: * -> *). Applicative q => Comp p q a -> Comp p q a) -> p a at T9834.hs:23:11 ?a1? is a rigid type variable bound by a type expected by the context: Applicative q => Comp p q a1 -> Comp p q a1 at T9834.hs:24:10 Expected type: Comp p q a1 -> Comp p q a1 Actual type: Comp p q a -> Comp p q a Relevant bindings include afix :: (forall (q :: * -> *). Applicative q => Comp p q a -> Comp p q a) -> p a (bound at T9834.hs:24:3) In the expression: wrapIdComp In an equation for ?afix?: afix = wrapIdComp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 16:35:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 16:35:25 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.06e8bf264f4fd9321e816e6334f1cddc@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Difficult (2-5 None/Unknown | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: I am in this area currently (planning to add split-objs support to the LLVM backend, which will require some refactoring somewhere), so will mark myself owner for now at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 16:58:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 16:58:31 -0000 Subject: [GHC] #7072: GHC interpreter does not find stat64 symbol on Linux In-Reply-To: <047.f18c5903feb6270f1e8b00e7eeb5b619@haskell.org> References: <047.f18c5903feb6270f1e8b00e7eeb5b619@haskell.org> Message-ID: <062.e83d464f41d84820153563a5b40326b5@haskell.org> #7072: GHC interpreter does not find stat64 symbol on Linux -------------------------------------+---------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Changes (by thomie): * cc: hvr (added) * status: new => closed * resolution: => fixed * milestone: 7.10.1 => Comment: GHCi on Linux has been using the system linker since 7.8.1, see [wiki:DynamicGhcPrograms], so this is no longer an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 17:11:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 17:11:04 -0000 Subject: [GHC] #7072: GHC interpreter does not find stat64 symbol on Linux In-Reply-To: <047.f18c5903feb6270f1e8b00e7eeb5b619@haskell.org> References: <047.f18c5903feb6270f1e8b00e7eeb5b619@haskell.org> Message-ID: <062.e25964fb615ff5f6cc1b3964cdace5c3@haskell.org> #7072: GHC interpreter does not find stat64 symbol on Linux -------------------------------------+---------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Changes (by hvr): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 17:15:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 17:15:18 -0000 Subject: [GHC] #5062: Patch: Debug output for OS X linker and coding standard upgrades In-Reply-To: <044.e9cb6f792ef8583a545d646b5271f602@haskell.org> References: <044.e9cb6f792ef8583a545d646b5271f602@haskell.org> Message-ID: <059.ae64beb803fa95445f54e2a9362d89c2@haskell.org> #5062: Patch: Debug output for OS X linker and coding standard upgrades -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Runtime | Version: 7.0.3 System | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 3658 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * difficulty: => Unknown * status: new => closed * resolution: => wontfix Comment: GHCi on OS X has been using the system linker since 7.8.1, see [wiki:DynamicGhcPrograms] and #3658. Please re-open if someone thinks there's still value in applying this patch to the old GHCi linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 17:19:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 17:19:40 -0000 Subject: [GHC] #5062: Patch: Debug output for OS X linker and coding standard upgrades In-Reply-To: <044.e9cb6f792ef8583a545d646b5271f602@haskell.org> References: <044.e9cb6f792ef8583a545d646b5271f602@haskell.org> Message-ID: <059.f185576c52c69f21e9667fe095a3d55e@haskell.org> #5062: Patch: Debug output for OS X linker and coding standard upgrades -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Runtime | Version: 7.0.3 System | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 3658 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 17:25:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 17:25:54 -0000 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@haskell.org> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@haskell.org> Message-ID: <058.95459a74822d72b8f045b4a35cc38995@haskell.org> #3654: Mach-O GHCi linker lacks support for a range of relocation entries -------------------------------------+------------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime | Version: 6.13 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: 3658 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * status: new => closed * resolution: => fixed * milestone: 7.10.1 => Comment: GHCi on OS X has been using the system linker since 7.8.1, see [wiki:DynamicGhcPrograms] and #3658, so this is no longer an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 18:36:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 18:36:27 -0000 Subject: [GHC] #7044: reject reading rationals with exponent notation In-Reply-To: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> References: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> Message-ID: <060.3839fd3390b46d505768ebab87ac36b3@haskell.org> #7044: reject reading rationals with exponent notation -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #5692,#7266 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #5692 => #5692,#7266 Comment: Note that with #7266, since 7.8.1, the example for integers is accepted: {{{ $ ghci -XNumDecimals ... Prelude> 1e10 :: Int 10000000000 }}} Along the same lines, should `(1E10 :: Rational)` only be accepted when `-XNumDecimals` is set? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 18:39:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 18:39:41 -0000 Subject: [GHC] #9059: Excessive space usage while generating code for fractional literals with big exponents In-Reply-To: <049.6d8f94befa1b5f7c36b68d142aab3d6d@haskell.org> References: <049.6d8f94befa1b5f7c36b68d142aab3d6d@haskell.org> Message-ID: <064.9e0e11c12fe5b6c229ea47141545eadb@haskell.org> #9059: Excessive space usage while generating code for fractional literals with big exponents -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #5688, #7044 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #5688, #7044 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 18:40:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 18:40:20 -0000 Subject: [GHC] #7044: reject reading rationals with exponent notation In-Reply-To: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> References: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> Message-ID: <060.3a7003f521d7541690ed7e1c276aa2a1@haskell.org> #7044: reject reading rationals with exponent notation -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #5692,#7266,#9059 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #5692,#7266 => #5692,#7266,#9059 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 19:08:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 19:08:19 -0000 Subject: [GHC] #7033: stale .tix files can cause programs built with -fhpc to segfault In-Reply-To: <045.bed67c61bb297a8eadaedd39cb0c4fef@haskell.org> References: <045.bed67c61bb297a8eadaedd39cb0c4fef@haskell.org> Message-ID: <060.1ec4cf801e49f27f3e588a1172500e3e@haskell.org> #7033: stale .tix files can cause programs built with -fhpc to segfault -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Code | Version: 7.4.2 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Confirmed with HEAD, ghc-7.9.20141121, although it never segfaults. I always get {{{ Hpc failure: module mismatch with .tix/.mix file hash number (perhaps remove foo.tix file?) }}} With 7.4.1, it segfaults about 10% of the times when I add `module Main where` to the top of `foo.hs`. To reproduce, save `foo.hs` and `Bar.hs` in subdirectory `original`. Then run the following script. {{{ set -x GHC=ghc rm foo* Bar* cp original/*.hs . $GHC -O -fhpc foo.hs ./foo cat foo.tix mv Bar.hs Bar.hs.orig sed -e 's/import/-- import/' -i.bak foo.hs rm -f *.hi *.o $GHC -O -fhpc foo.hs ./foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 20:36:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 20:36:23 -0000 Subject: [GHC] #9835: Add bindings for marshaling to/from mpz_t Message-ID: <046.1c6d53a654b67e9b3184380a77d8544d@haskell.org> #9835: Add bindings for marshaling to/from mpz_t -------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.3 Keywords: integer-gmp | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Please add bindings to allow efficient marshaling between Haskell Integer and C mpz_t's, e.g.: {{{ -- Wraps a (struct __mpz_struct*). type Mpz = Ptr () toMpz :: Integer -> IO Mpz fromMpz :: Mpz -> IO Integer }}} This would be useful for efficiently interfacing with foreign code that uses GMP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 22:41:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 22:41:54 -0000 Subject: [GHC] #9835: Add bindings for marshaling to/from mpz_t In-Reply-To: <046.1c6d53a654b67e9b3184380a77d8544d@haskell.org> References: <046.1c6d53a654b67e9b3184380a77d8544d@haskell.org> Message-ID: <061.cd54687f109dc6c77310313616c68f21@haskell.org> #9835: Add bindings for marshaling to/from mpz_t -------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: libraries | Keywords: integer-gmp (other) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): For one, `integer-gmp` has been completely rewritten, see #9281. Otoh, things like this should easily be implementable outside of `integer-gmp` in a 3rd party package. Alas, conversions between `Integer` and a `Mpz` pointer will involve allocations and `memcpy`s -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 25 23:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Nov 2014 23:14:33 -0000 Subject: [GHC] #9835: Add bindings for marshaling to/from mpz_t In-Reply-To: <046.1c6d53a654b67e9b3184380a77d8544d@haskell.org> References: <046.1c6d53a654b67e9b3184380a77d8544d@haskell.org> Message-ID: <061.96682dedc2f7c6d5e157e595e31bc135@haskell.org> #9835: Add bindings for marshaling to/from mpz_t -------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: libraries | Keywords: integer-gmp (other) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfranke): > Things like this should easily be implementable outside of integer-gmp in a 3rd party package. I wrote it this morning :-). But since it relies on internals of both integer-gmp (treating `Integer` non-opaquely) and libgmp (treating `struct __mpz_struct` non-opaquely), I think having it merged into integer-gmp would create fewer maintenance headaches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 00:16:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 00:16:09 -0000 Subject: [GHC] #7044: reject reading rationals with exponent notation In-Reply-To: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> References: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> Message-ID: <060.b8bbf6016c28c3dfac32af0be745c82f@haskell.org> #7044: reject reading rationals with exponent notation -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #5692,#7266,#9059 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): What am I missing here? Why shouldn't such a thing be allowed? This particular example *should* just run out of memory. Others should work correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 01:13:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 01:13:58 -0000 Subject: [GHC] #7033: stale .tix files can cause programs built with -fhpc to segfault In-Reply-To: <045.bed67c61bb297a8eadaedd39cb0c4fef@haskell.org> References: <045.bed67c61bb297a8eadaedd39cb0c4fef@haskell.org> Message-ID: <060.bd42e34347ddc1ed32329bf6f921705f@haskell.org> #7033: stale .tix files can cause programs built with -fhpc to segfault -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Code | Version: 7.4.2 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jwlato): If HEAD never segfaults and always gives an error about a module mismatch, wouldn't that mean the bug is fixed? Unfortunately I won't be able to check myself for some time, but if it works for other people I'm satisfied it's fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 06:39:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 06:39:01 -0000 Subject: [GHC] #7647: UNPACK polymorphic fields In-Reply-To: <045.8091f80cf766b683cf12520609e77aee@haskell.org> References: <045.8091f80cf766b683cf12520609e77aee@haskell.org> Message-ID: <060.c25456aa2a95084e9820d9bdc28f22d8@haskell.org> #7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 3990 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by akio): * cc: tkn.akio@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 07:56:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 07:56:40 -0000 Subject: [GHC] #9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation Message-ID: <042.f26aa5502ae18a92677b97b72d2d86fd@haskell.org> #9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: Data.Version | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: #2496 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- See https://groups.google.com/forum/#!topic/haskell-core-libraries/q9H- QlL_gnE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 07:57:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 07:57:58 -0000 Subject: [GHC] #9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation In-Reply-To: <042.f26aa5502ae18a92677b97b72d2d86fd@haskell.org> References: <042.f26aa5502ae18a92677b97b72d2d86fd@haskell.org> Message-ID: <057.bae0732f7ecf962afef7e47de648dca8@haskell.org> #9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Data.Version Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: #2496 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 08:05:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 08:05:04 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.59dc2c252f9a22d70ebca2125c9b9ba8@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"4bf055c70d07b98be1e7749e0306e406dfbbc006/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4bf055c70d07b98be1e7749e0306e406dfbbc006" Define `Data` instance for `Natural` type (#9818) This follows the same style as the other integral `Data` instances defined in the `Data.Data` module. Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D526 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 09:08:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 09:08:49 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.b9317c974088c2550234820f43e3a8ec@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: I noticed that this did not make it into 7.8.4-rc1. I thought that?s what "merged in ..." meant... but now I see that you did not merge the amd64 support, but rather some alias handling. Marking this as merge in case this is just an oversight, and there was a plan to merge the AMD64 support in 7.8.4. Just close it again if that was not the intention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 09:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 09:09:14 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.34e47d5cad4af698df629be2244f224b@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 09:43:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 09:43:01 -0000 Subject: [GHC] #9835: Add bindings for marshaling to/from mpz_t In-Reply-To: <046.1c6d53a654b67e9b3184380a77d8544d@haskell.org> References: <046.1c6d53a654b67e9b3184380a77d8544d@haskell.org> Message-ID: <061.70a9f1a07030ca3a10796871840d6e08@haskell.org> #9835: Add bindings for marshaling to/from mpz_t -------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: libraries | Keywords: integer-gmp (other) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #7860 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #7860 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 09:45:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 09:45:07 -0000 Subject: [GHC] #9835: Add bindings for marshaling to/from mpz_t In-Reply-To: <046.1c6d53a654b67e9b3184380a77d8544d@haskell.org> References: <046.1c6d53a654b67e9b3184380a77d8544d@haskell.org> Message-ID: <061.4568990bc7212ebd2ac6855129c8d20d@haskell.org> #9835: Add bindings for marshaling to/from mpz_t -------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: libraries | Keywords: integer-gmp (other) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3489,#7860 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #7860 => #3489,#7860 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 09:45:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 09:45:33 -0000 Subject: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp' In-Reply-To: <046.cf50459cade182946253e5602ab21f1f@haskell.org> References: <046.cf50459cade182946253e5602ab21f1f@haskell.org> Message-ID: <061.54c1d3b4be437de93026b1919d3fab52@haskell.org> #7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: gmp Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3489, 9835 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #3489 => #3489, 9835 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 09:50:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 09:50:04 -0000 Subject: [GHC] #7033: stale .tix files can cause programs built with -fhpc to segfault In-Reply-To: <045.bed67c61bb297a8eadaedd39cb0c4fef@haskell.org> References: <045.bed67c61bb297a8eadaedd39cb0c4fef@haskell.org> Message-ID: <060.38c4a242f2493e22b3a5cd1b48d7bb3e@haskell.org> #7033: stale .tix files can cause programs built with -fhpc to segfault -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Code | Version: 7.4.2 Coverage | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: 7.10.1 => Comment: It doesn't segfault in 7.8.3 either actually (but it does in 7.8.2). Let's close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 09:53:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 09:53:10 -0000 Subject: [GHC] #7044: reject reading rationals with exponent notation In-Reply-To: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> References: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> Message-ID: <060.0c143599bb63ccd070d46067a9efb647@haskell.org> #7044: reject reading rationals with exponent notation -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #5692,#7266,#9059 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): The problem is that ghc runs out of memory at compile time, see #5692. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 09:54:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 09:54:44 -0000 Subject: [GHC] #9834: GHC panic when used with deferred type errors In-Reply-To: <051.4829af2311d69829d3866ca80599e051@haskell.org> References: <051.4829af2311d69829d3866ca80599e051@haskell.org> Message-ID: <066.13dd122abf346c295d1dabd2470c64f8@haskell.org> #9834: GHC panic when used with deferred type errors -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): I just checked and I'm getting a panic on my branch forked from HEAD 5 days ago. So if the fix indeed went into HEAD it must be really recent. I tried cherry-picking 2cc854b7133e38c7ad1107057931761782d03594 onto my branch because it does typed-holes-related stuff but that doesn't fix the panic. I also confirmed that this happens with GHC 7.8.4: Aside: To get the reported test case compiling with HEAD I had to change `import Control.Monad.Identity` to `import Data.Functor.Identity`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 13:21:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 13:21:29 -0000 Subject: [GHC] #9834: GHC panic when used with deferred type errors In-Reply-To: <051.4829af2311d69829d3866ca80599e051@haskell.org> References: <051.4829af2311d69829d3866ca80599e051@haskell.org> Message-ID: <066.c832d28b2433b1dd3613bae2fb16cecf@haskell.org> #9834: GHC panic when used with deferred type errors -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"cb9bcecceae5e6df758d0973ed0e496a07d15026/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cb9bcecceae5e6df758d0973ed0e496a07d15026" Test Trac #9834 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 13:22:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 13:22:13 -0000 Subject: [GHC] #9834: GHC panic when used with deferred type errors In-Reply-To: <051.4829af2311d69829d3866ca80599e051@haskell.org> References: <051.4829af2311d69829d3866ca80599e051@haskell.org> Message-ID: <066.13fb29e75487f31e6f0f03b643e2304d@haskell.org> #9834: GHC panic when used with deferred type errors -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | typecheck/should_compile/T9834 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T9834 Comment: OK well maybe it is recent, but at least it works now. I've added the module as a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 13:23:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 13:23:12 -0000 Subject: [GHC] #9834: GHC panic when used with deferred type errors In-Reply-To: <051.4829af2311d69829d3866ca80599e051@haskell.org> References: <051.4829af2311d69829d3866ca80599e051@haskell.org> Message-ID: <066.4dd26f84b1f16eb7b08185c7f3dc1bd7@haskell.org> #9834: GHC panic when used with deferred type errors -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: GHCi crash | Related Tickets: Test Case: | typecheck/should_compile/T9834 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I'll close this, because I think it unlikely we'll ever do 7.8.5 and we don't know what to merge across even if we did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 14:14:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 14:14:13 -0000 Subject: [GHC] #9837: Introduce a logging API to GHC Message-ID: <047.adb1a804fb52c7dc4c827ad80fa6f2c8@haskell.org> #9837: Introduce a logging API to GHC -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I don't have a lot of mileage with the code base, but I do see that there is no standard logging API that the various components can use (or there is and it just needs to be used??). At least, I would expect to see a standard API to generate log entries with the following minimal parts: * timestamp * Log level - for example, ERROR, WARN, INFO, DEBUG, TRACE (-v[1-3] could map to INFO, DEBUG and TRACE. Log levels are inclusive so INFO also means WARN and ERROR. * Component name - so we know what is the source of the log message. At least I would expect to see (Desugarer, Typechecker, Parser, etc) * the message It would also mean a single back-end to collect the log messages and dump them to a file, stdout/stderr, etc. There are many other features beyond this point (customize log messages, colors, filtering, etc), but in terms of the API that is used throughout the code base, it should be simple. Was this already discussed in the past? Is there already such an API in the codebase? Is there an existing library that we could use to achieve the same? Any other ideas? This ticket is mostly to spawn a discussion about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 14:33:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 14:33:32 -0000 Subject: [GHC] #7044: reject reading rationals with exponent notation In-Reply-To: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> References: <045.23151b7ec469d5d8e7b33ae5766565fb@haskell.org> Message-ID: <060.aca21c5c76e85ba1b817337d7d5c83dd@haskell.org> #7044: reject reading rationals with exponent notation -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #5692,#7266,#9059 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:9 thomie]: > The problem is that ghc runs out of memory at compile time, see #5692. That's unfortunate, but I think to be expected. Banning the notation is the wrong fix; it'd make more sense to limit it based on size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 14:55:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 14:55:49 -0000 Subject: [GHC] #6149: ghc-7.4.2 tests for profasm seg-fault under solaris In-Reply-To: <045.09ee87f0312411809b142c24cdf75258@haskell.org> References: <045.09ee87f0312411809b142c24cdf75258@haskell.org> Message-ID: <060.a63d3caab3ea2649e3eb44bd1ad5c419@haskell.org> #6149: ghc-7.4.2 tests for profasm seg-fault under solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2-rc1 Resolution: wontfix | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: This ticket is about test results for the 7.4.2 release, which are probably no longer relevant. Some fixes for Solaris were made in the past 2 years (`git log --grep=solaris`), but please open a new ticket if there are still problems with HEAD on Solaris. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 15:01:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 15:01:32 -0000 Subject: [GHC] #6113: Profiling with -p not written if killed with SIGTERM In-Reply-To: <045.764bc656e63c4390b5e307b27a89b060@haskell.org> References: <045.764bc656e63c4390b5e307b27a89b060@haskell.org> Message-ID: <060.5c9b9bac2d4d6f560faeb2812dfa04fc@haskell.org> #6113: Profiling with -p not written if killed with SIGTERM -------------------------------------+------------------------------------- Reporter: Veinor | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Profiling | Version: 7.4.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): See #9715 for another report of this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 15:02:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 15:02:36 -0000 Subject: [GHC] #9715: The most minimal Gloss project causes the profiler to fail silently. In-Reply-To: <044.6ce93f62a8ca3e7527c71ce3cdf48228@haskell.org> References: <044.6ce93f62a8ca3e7527c71ce3cdf48228@haskell.org> Message-ID: <059.81f5601b190149c6fc95c6c607e3c578@haskell.org> #9715: The most minimal Gloss project causes the profiler to fail silently. -------------------------------------+------------------------------------- Reporter: Yxven | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: This is most likely a duplicate of #6113. Feel free to re-open if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 15:14:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 15:14:40 -0000 Subject: [GHC] #6107: GHCi runtime linker cannot link with duplicate common symbols In-Reply-To: <046.ed2058fbb6b102a7e0a7609832647662@haskell.org> References: <046.ed2058fbb6b102a7e0a7609832647662@haskell.org> Message-ID: <061.d4842f5c931bb34f29a6a5f2faeed022@haskell.org> #6107: GHCi runtime linker cannot link with duplicate common symbols -------------------------------------+------------------------------------- Reporter: exFalso | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: 8228 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Linux => Windows * blockedby: 3658 => 8228 Comment: GHCi on Linux has been using the system linker since 7.8.1, see [wiki:DynamicGhcPrograms] and #3658. I'll leave this ticket open for Windows only. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 15:15:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 15:15:35 -0000 Subject: [GHC] #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.6f829de48e33b5b19b1c8f93bc3279b6@haskell.org> #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4213 | Differential Revisions: Phab:D155 | -------------------------------------+------------------------------------- Comment (by nomeata): Is this something that will be merged into 7.8? (I?m not sure if Debian has llvm-3.4 around for as long as we will have 7.8 around.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 15:31:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 15:31:13 -0000 Subject: [GHC] #6098: debugger does not know the correct type for a newtype field In-Reply-To: <046.a6a3ed9e9606c79c8b19751897c4a128@haskell.org> References: <046.a6a3ed9e9606c79c8b19751897c4a128@haskell.org> Message-ID: <061.6ecc1f8565af85f535361d44692389eb@haskell.org> #6098: debugger does not know the correct type for a newtype field -------------------------------------+------------------------------------- Reporter: phercek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.4.2 Resolution: fixed | Keywords: debugger bindings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * os: Linux => Unknown/Multiple * version: 7.5 => 7.4.2 * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: 7.10.1 => * resolution: => fixed Comment: This was fixed in the 7.8.1 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 16:13:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 16:13:21 -0000 Subject: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp' In-Reply-To: <046.cf50459cade182946253e5602ab21f1f@haskell.org> References: <046.cf50459cade182946253e5602ab21f1f@haskell.org> Message-ID: <061.22e8dcebe2b342bb1d69e5703f0117b2@haskell.org> #7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Core | Keywords: gmp Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3489, 9835 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): `integer-gmp2` does in fact already have a popcount primop (and it's used by `Integer` and `Natural`) Fwiw, I'm planning to implement set/clearbit for integer-gmp2, at the latest for GHC 7.12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 17:09:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 17:09:57 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.35a8a3aa28eab95dd6c611b0d988ccda@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"ed56c023e3e2e3d2a9fe18a17e2131d9a55c69a5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ed56c023e3e2e3d2a9fe18a17e2131d9a55c69a5" Use {bit,popCount}Integer for `Bits Integer` The primops are implemented in the `integer-gmp2` (#9281) backend and are already used for the `Bits Natural` instance but aren't used yet for the `Bits Integer` instace. This commit fixes that. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 18:16:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 18:16:10 -0000 Subject: [GHC] #6024: Allow defining kinds alone, without a datatype In-Reply-To: <046.e44bc03833a60dff474759358b4e4e3f@haskell.org> References: <046.e44bc03833a60dff474759358b4e4e3f@haskell.org> Message-ID: <061.d2dcb4dedbc1eca1fa3860e9c480bcd0@haskell.org> #6024: Allow defining kinds alone, without a datatype -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.5 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 21:04:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 21:04:17 -0000 Subject: [GHC] #9837: Introduce a logging API to GHC In-Reply-To: <047.adb1a804fb52c7dc4c827ad80fa6f2c8@haskell.org> References: <047.adb1a804fb52c7dc4c827ad80fa6f2c8@haskell.org> Message-ID: <062.a9be9139ad66716ee614c11444009bb8@haskell.org> #9837: Introduce a logging API to GHC -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I think the ghc events log already provides the machinery for this sort of thing. I dont think that those notions of log levels necessarily make sense in the RTS though. (though i could be wrong) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 21:30:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 21:30:06 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. Message-ID: <045.0b65349f28e5656b4f336583aec26453@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently both PatternSynonyms and ConstraintKinds have to be enabled at the usage site, not just at the construction site. This pretty much ensures that they'll never be used to 'clean up' or virtualize an existing API, because switching to pattern synonyms for constructors or switching a 'class alias' to a type synonym immediately break all users. For instance right now, as a user I universally write {{{ class (Foo a, Bar a) => Baz a instance (Foo a, Bar a) => Baz a }}} rather than {{{ type Baz a = (Foo a, Bar a) }}} because the former gives a better user experience and I can pay all the extensions needed for it at the definition site, rather than have all my users pay them at the use site. I'd like to propose that the language extensions for these two cases, `PatternSynonyms` and `ConstraintKinds` only be required at the definition site, rather than at the use site. The former is definitely needed at the definition site because of the new syntax, but unless you explicitly re-export a pattern, no syntax changes at the usage site. This would also be more consistent with existing policies for other extensions: We don't require users to turn on FunctionalDependencies to get the benefit of functional dependencies, or to turn on MultiParamTypeClasses to use an MPTC, merely to define them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 21:42:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 21:42:15 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.a0b6e3e97a4fe7314b2ca2192fc66f96@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: cactus, goldfire (added) Comment: I agree 100%. Requiring a language extension flag at the definition but not the use is definitely GHC's standard policy. (Eg overlapping instances.) I understand about pattern synonyms. Gergo, could you look at this? I don't understand about constraint kinds. Can you give a concrete example? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 21:59:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 21:59:07 -0000 Subject: [GHC] #9837: Introduce a logging API to GHC In-Reply-To: <047.adb1a804fb52c7dc4c827ad80fa6f2c8@haskell.org> References: <047.adb1a804fb52c7dc4c827ad80fa6f2c8@haskell.org> Message-ID: <062.9a37532782571214e4eac5a500d22497@haskell.org> #9837: Introduce a logging API to GHC -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): Yes, I opened the ticket thinking about the compiler not the runtime. Right now if you turn the verbosity on you will see a blob of output that is hard to parse and could benefit from a tidy up. Maybe the current v[1-3] is already good enough, I think the main point is to centralize logging. Again, if there is a pattern to this that I am missing here, please let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 22:33:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 22:33:07 -0000 Subject: [GHC] #6022: GHC infers over-general types In-Reply-To: <046.17a0376aec11ac55102e23a3c30540d1@haskell.org> References: <046.17a0376aec11ac55102e23a3c30540d1@haskell.org> Message-ID: <061.7f6deb6592cb7e97d3d8b4934193df62@haskell.org> #6022: GHC infers over-general types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): GHC should reject `f` ''without'' type signature, because it also rejects `f` ''with'' type signature, unless `FlexibleContexts` is enabled. {{{ Prelude> let f x = x + head -- GHC should complain here Prelude> :t f f :: Num ([a] -> a) => ([a] -> a) -> [a] -> a Prelude> let f :: Num ([a] -> a) => ([a] -> a) -> [a] -> a; f x = x + head :4:10: Non type-variable argument in the constraint: Num ([a] -> a) (Use FlexibleContexts to permit this) In the type signature for ?f?: f :: Num ([a] -> a) => ([a] -> a) -> [a] -> a Prelude> :set -XFlexibleContexts Prelude> let f :: Num ([a] -> a) => ([a] -> a) -> [a] -> a; f x = x + head Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 22:48:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 22:48:52 -0000 Subject: [GHC] #6022: GHC infers over-general types In-Reply-To: <046.17a0376aec11ac55102e23a3c30540d1@haskell.org> References: <046.17a0376aec11ac55102e23a3c30540d1@haskell.org> Message-ID: <061.47060406891767cb2a91cbc000e02679@haskell.org> #6022: GHC infers over-general types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8883 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #8883 Comment: I now realize HEAD does exactly that, see #8883. I'm not sure if an extra regression is needed, but here's what it would look like: {{{ $ cat T6022.hs module T6022 where f x = x + head $ ghc-7.9.20141125 T6022.hs [1 of 1] Compiling T6022 ( T6022.hs, T6022.o ) T6022.hs:2:1: Non type-variable argument in the constraint: Num ([a] -> a) (Use FlexibleContexts to permit this) When checking that ?f? has the inferred type f :: forall a. Num ([a] -> a) => ([a] -> a) -> [a] -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 23:09:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 23:09:21 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.85c79a8a54c4e3b9a2a83553335117a2@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: #9324 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): > Perhaps just improve the warning message to explain to the user exactly what is making GHCi unhappy and how to fix it? Improving the current warning is certainly a good idea. For a discussion to make reading of .ghci files even stricter, see #6017. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 23:11:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 23:11:54 -0000 Subject: [GHC] #6017: Reading ./.ghci files raises security issues In-Reply-To: <046.4c80215545a1055cdc72cec5a74c2a85@haskell.org> References: <046.4c80215545a1055cdc72cec5a74c2a85@haskell.org> Message-ID: <061.cb37a9a1e7f3014320c5d4651451ae57@haskell.org> #6017: Reading ./.ghci files raises security issues -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: #8248 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8248 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 23:22:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 23:22:20 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.79ff274f213aa01b0f07bd202d987be1@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Btw, here's a related [https://groups.google.com/forum/#!msg/haskell-core- libraries/q9H-QlL_gnE/WUSqogVY89QJ CLC posting of mine] showing a concrete use-case for pattern-synonyms which is hindered by requiring `-XPatternSynonyms` at the usage-site... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 23:27:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 23:27:38 -0000 Subject: [GHC] #5985: Type operators are not accepted as variables in contexts In-Reply-To: <057.7e28b981cb9797ca2708f299694e710e@haskell.org> References: <057.7e28b981cb9797ca2708f299694e710e@haskell.org> Message-ID: <072.0ae9452f4c59012b28ca3ac7ea25fbaf@haskell.org> #5985: Type operators are not accepted as variables in contexts -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Status: new Type: feature | Milestone: 7.10.1 request | Version: 7.5 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request Comment: For reference, a link to the section [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data- type-extensions.html#type-operators Type operators] in the users's guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 23:34:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 23:34:26 -0000 Subject: [GHC] #5983: Libraries installed in wrong place In-Reply-To: <043.e001f11b98ff611be59707db8af989df@haskell.org> References: <043.e001f11b98ff611be59707db8af989df@haskell.org> Message-ID: <058.1a83670fe9e06a7fde953585fec36a4e@haskell.org> #5983: Libraries installed in wrong place ---------------------------------------+---------------------------------- Reporter: r0ml | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8266 Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * component: Core Libraries => Compiler * related: => #8266 * milestone: 7.10.1 => Comment: Replying to [comment:4 darchon]: > Probably fixed by #8266 Dynamic linking has been much improved on OS X. But please re-open if there is still an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 26 23:36:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Nov 2014 23:36:08 -0000 Subject: [GHC] #5982: Incorrect dynamic library name in OSX In-Reply-To: <043.e9dbce1f8a84aa40b605402efe6d469c@haskell.org> References: <043.e9dbce1f8a84aa40b605402efe6d469c@haskell.org> Message-ID: <058.361896e271c11c3a529fc3339ae14cb8@haskell.org> #5982: Incorrect dynamic library name in OSX ----------------------------------------+---------------------------------- Reporter: r0ml | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8266 Differential Revisions: | ----------------------------------------+---------------------------------- Changes (by thomie): * component: Core Libraries => Compiler * related: => #8266 * milestone: 7.10.1 => Comment: > Probably now fixed with #8266 Dynamic linking has been much improved on OS X. But please re-open if there is still an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 00:15:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 00:15:41 -0000 Subject: [GHC] #5942: implement POSIX confstr() in System/Posix/Unistd.hsc In-Reply-To: <044.38f223780cc18019938795698948babf@haskell.org> References: <044.38f223780cc18019938795698948babf@haskell.org> Message-ID: <059.bcd7340c8a7ab75722b28049e5548f26@haskell.org> #5942: implement POSIX confstr() in System/Posix/Unistd.hsc -------------------------------------+------------------------------------- Reporter: clint | Owner: ekmett Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Core | Keywords: confstr Libraries | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => wontfix Comment: The change you are requesting has to go through the [https://www.haskell.org/haskellwiki/Library_submissions library submission process] first (basically send an email to libraries at haskell.org). Please submit a pull request to https://github.com/haskell/unix once your proposal is accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 00:23:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 00:23:00 -0000 Subject: [GHC] #5941: Add compilation stage plugins In-Reply-To: <044.b57cf00ec831ffd77a7e1faf72cc142b@haskell.org> References: <044.b57cf00ec831ffd77a7e1faf72cc142b@haskell.org> Message-ID: <059.66a2944c540ff5e4d7fbc8bf466f4f5b@haskell.org> #5941: Add compilation stage plugins -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Is this feature request covered by [wiki:Plugins/TypeChecker], Phab:D489? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 00:24:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 00:24:57 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.d67919e28171b0cd3bbcc1906ddd782a@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 00:27:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 00:27:22 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.a076fa190148a349eefdbd7fe65f786f@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Re: `ConstraintKinds` You can construct a fairly simple example where someone wants to have something that they can put in a context that, say, offered both `Applicative m` and `Monad m` as a stopgap for the AMP. {{{ class (Applicative m, Monad m) => ApplicativeMonad m instance (Applicative m, Monad m) => ApplicativeMonad m }}} as opposed to {{{ type ApplicativeMonad m = (Applicative m, Monad m) }}} Similar hack-arounds are common among folks who see `Semigroup` as a superclass of `Monoid`, but who have to workaround the lack of a superclass relationship. These sorts of synonyms are actually quite common, I think I first used it back around 2006 when I first found haskell: e.g. TXOr in http://hackage.haskell.org/package/type-int-0.5.0.2/docs/src/Data-Type- Boolean.html#TXOr is an instance of this pattern, but it was a well known pattern long before the time I started using it. The former requires "scarier" extensions than the latter for the person constructing it, but the latter requires an extension to be turned on by the user, hoisting the library designer upon the horns of a dilemma, do they take the burden upon themselves and use "the old way" of thinking about these things or do they make every user turn on `ConstraintKinds`? Mind you it still isn't a clean decision even with this change, because the former still works better in some scenarios, e.g. you can pass the class/instance version of `ApplicativeMonad` as an argument that expects something of kind `(* -> *) -> Constraint`, but the type synonym version cannot be partially applied, but these are the kinds of thoughts users of `ConstraintKinds` wind up thinking. Almost all of my current real world examples of this are now entangled with this secondary concern: e.g. https://github.com/ekmett/hask/blob/master/src/Hask/Category.hs#L93 gets partially applied in https://github.com/ekmett/hask/blob/master/src/Hask/Category.hs#L283 https://github.com/ekmett/hask/blob/master/src/Hask/Category/Polynomial.hs#L35 gets partially applied in https://github.com/ekmett/hask/blob/master/src/Hask/Category/Polynomial.hs#L50 etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 00:29:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 00:29:30 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.64e0105f526d0e8895efa1ea25e351ca@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 00:35:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 00:35:46 -0000 Subject: [GHC] #5910: Holes with other constraints In-Reply-To: <045.7ce17b393921f6c85549a3e0d688b66c@haskell.org> References: <045.7ce17b393921f6c85549a3e0d688b66c@haskell.org> Message-ID: <060.058345f0e23a216fc209603e58e32155@haskell.org> #5910: Holes with other constraints -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.5 Component: Compiler | Keywords: holes (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:22 simonpj]: > OK, so holes are now in HEAD. > > They lack > * documentation > * tests of any kind > > Two more actions: > * '''Sean or Thijs, could you add documentation and tests?''' > > * I think the idea of allowing undefined variables to turn into holes is a good one; so I'll leave the ticket open for that too. Did those tests ever get added? What is left to do here? See also #9091. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 00:40:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 00:40:21 -0000 Subject: [GHC] #5907: Crashed loading package Safe In-Reply-To: <044.9436eb6074fdd0789b5a9c65c85002c5@haskell.org> References: <044.9436eb6074fdd0789b5a9c65c85002c5@haskell.org> Message-ID: <059.647c97811a3b1950b2e98f4a758f4966@haskell.org> #5907: Crashed loading package Safe -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Package | Version: 7.0.3 system | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: Sorry, there won't be another 7.0.x release. Please try the latest version from https://www.haskell.org/ghc/download or the [https://haskell.org/platform Haskell platform]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 00:45:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 00:45:21 -0000 Subject: [GHC] #5898: ghc: internal error: Invalid Mach-O file In-Reply-To: <047.4caa59676d4622166f83f59fdc5cedfe@haskell.org> References: <047.4caa59676d4622166f83f59fdc5cedfe@haskell.org> Message-ID: <062.75f16eef836c9f63aee0ede561261b1d@haskell.org> #5898: ghc: internal error: Invalid Mach-O file ---------------------------------------+--------------------------- Reporter: jeffshaw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.4 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Linking on OS X has been much improved in the GHC 7.8 series. Please try the latest [https://www.haskell.org/ghc/ release], and don't hesitate to re-open this ticket if you encounter the same problem again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 01:11:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 01:11:28 -0000 Subject: [GHC] #5859: unsafeInterleaveIO duplicates computation when evaluated by multiple threads In-Reply-To: <048.e16c51f2c4eb0e9d277ad80547cd1eb9@haskell.org> References: <048.e16c51f2c4eb0e9d277ad80547cd1eb9@haskell.org> Message-ID: <063.bacdb1220a45a6de80c23bafaa55cecb@haskell.org> #5859: unsafeInterleaveIO duplicates computation when evaluated by multiple threads -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Core | Version: 7.2.2 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => fixed * milestone: 7.10.1 => Comment: Replying to [comment:6 simonpj]: > Cf #5943. Since `unsafeDupableInterleaveIO` is now NONINLINE, the symptoms of this ticket might have gone away. I confirm, as did bgamari: > Indeed I can't reproduce the buggy behavior with 7.6.2 and 7.7 HEAD. For reference, in commit bbcf397765953798b6d730c2bd1088c3463f3f5b: {{{ Author: Simon Marlow <> Date: Fri Mar 23 12:28:18 2012 +0000 change unsafeDupableInterleaveIO from INLINE to NOINLINE (#5943) See the comment for details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 01:13:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 01:13:03 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.8e88e0e6529f69be36f89edcf5c30f45@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: | Owner: JamesFisher | Status: new Type: feature | Milestone: 7.10.1 request | Version: 7.4.1 Priority: normal | Keywords: newcomer Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 01:18:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 01:18:08 -0000 Subject: [GHC] #5841: seg fault in ghci but not ghc when using chart-gtk code In-Reply-To: <045.c0e839d25fa2feaad1e3187f69ad582f@haskell.org> References: <045.c0e839d25fa2feaad1e3187f69ad582f@haskell.org> Message-ID: <060.7543b0e1ad673235af87eef13d7b792d@haskell.org> #5841: seg fault in ghci but not ghc when using chart-gtk code ---------------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5816 Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by thomie): * related: 5816 => #5816 * milestone: 7.10.1 => Comment: Replying to [comment:4 carter]: > My understanding is that the switch to dylibs for ghci should resolve many of the "funny problems with ghci" bugs people have had over the years. Indeed, let's close this. For anyone reading this in the future: please re-open this ticket or open a new ticket when you have any kind linking problem with GHC on OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 01:20:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 01:20:37 -0000 Subject: [GHC] #5840: Extend the supported environment sizes of vectorised closures In-Reply-To: <052.50c5618a3a29f94f7c90c43a8b7eafa9@haskell.org> References: <052.50c5618a3a29f94f7c90c43a8b7eafa9@haskell.org> Message-ID: <067.8efc1e323b03424d2eda7027e07fd071@haskell.org> #5840: Extend the supported environment sizes of vectorised closures -------------------------------------+------------------------------------- Reporter: | Owner: chak mukesh.tiwari | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Data | Keywords: Parallel Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #7330 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #7330 Comment: Is this still an issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 01:21:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 01:21:10 -0000 Subject: [GHC] #5840: Extend the supported environment sizes of vectorised closures In-Reply-To: <052.50c5618a3a29f94f7c90c43a8b7eafa9@haskell.org> References: <052.50c5618a3a29f94f7c90c43a8b7eafa9@haskell.org> Message-ID: <067.1e12b51340b55dcadb10d6c11c566a3d@haskell.org> #5840: Extend the supported environment sizes of vectorised closures -------------------------------------+------------------------------------- Reporter: | Owner: chak mukesh.tiwari | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Data | Keywords: Parallel Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #7330 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 01:35:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 01:35:30 -0000 Subject: [GHC] #5835: Make better use of known dictionaries In-Reply-To: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> References: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> Message-ID: <056.fc74c1fd02799684d4a48c05a11b1f9f@haskell.org> #5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.5 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug Old description: > Example: > > {{{ > data T a where > T :: Eq a => a -> T a > > foo :: a -> T a -> Bool > {-# INLINE foo #-} > foo x = \(T y) -> x == y > > appl :: (a -> b) -> a -> b > {-# NOINLINE appl #-} > appl f x = f x > > bar :: T Int -> Bool > bar t = appl (foo 42) t > }}} > > GHC generates this for `bar`: > > {{{ > bar2 :: Int > bar2 = I# 42 > > bar1 :: T Int -> Bool > bar1 = > \ (ds_dhk :: T Int) -> > case ds_dhk of _ { T $dEq_agz y_aa4 -> > == @ Int $dEq_agz bar2 y_aa4 > } > > bar :: T Int -> Bool > bar = \ (t_aga :: T Int) -> appl @ (T Int) @ Bool bar1 t_aga > }}} > > Note how it want to get the `Eq` dictionary for `Int` from `T`. But we > know the `Eq Int` instance without inspecting `T` and `bar` could be > significantly simplified if we used that. New description: Example: {{{ {-# LANGUAGE GADTs #-} module T5835 where data T a where T :: Eq a => a -> T a foo :: a -> T a -> Bool {-# INLINE foo #-} foo x = \(T y) -> x == y appl :: (a -> b) -> a -> b {-# NOINLINE appl #-} appl f x = f x bar :: T Int -> Bool bar t = appl (foo 42) t }}} GHC generates this for `bar`: {{{ bar2 :: Int bar2 = I# 42 bar1 :: T Int -> Bool bar1 = \ (ds_dhk :: T Int) -> case ds_dhk of _ { T $dEq_agz y_aa4 -> == @ Int $dEq_agz bar2 y_aa4 } bar :: T Int -> Bool bar = \ (t_aga :: T Int) -> appl @ (T Int) @ Bool bar1 t_aga }}} Note how it want to get the `Eq` dictionary for `Int` from `T`. But we know the `Eq Int` instance without inspecting `T` and `bar` could be significantly simplified if we used that. -- Comment: Core unchanged in HEAD vs 7.5. To reproduce, use this command: `ghc -O2 -ddump-simpl -dsuppress-module-prefixes -dsuppress-idinfo T5835.hs` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 01:36:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 01:36:56 -0000 Subject: [GHC] #5834: Allow both INLINE and INLINABLE for the same function In-Reply-To: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> References: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> Message-ID: <056.af01e5ce0e62496e9afaa8ee285b77f5@haskell.org> #5834: Allow both INLINE and INLINABLE for the same function -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.5 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 01:53:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 01:53:05 -0000 Subject: [GHC] #5827: /usr/local hard-coded in cabal In-Reply-To: <043.a23b3eec0e904dc5ffd970a19172f5ed@haskell.org> References: <043.a23b3eec0e904dc5ffd970a19172f5ed@haskell.org> Message-ID: <058.7b59101e649b646c57c6305e90e02537@haskell.org> #5827: /usr/local hard-coded in cabal -------------------------------------+------------------------------------- Reporter: donn | Owner: duncan Type: bug | Status: closed Priority: normal | Milestone: Component: Core | Version: 7.4.1-rc2 Libraries | Keywords: Cabal Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Other | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => duplicate * milestone: 7.10.1 => Comment: I have re-raised this ticket in the Cabal issue tracker: https://github.com/haskell/cabal/issues/2240. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 02:04:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 02:04:16 -0000 Subject: [GHC] #5821: SPECIALISE fails with a cryptic warning In-Reply-To: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> References: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> Message-ID: <056.cf5ecc41dd661825ff7f694b71a6b782@haskell.org> #5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): In HEAD, the error message for the program from the description has changed to: {{{ $ ghc-7.9.20141125 T5821.hs [1 of 1] Compiling T5821 ( T5821.hs, T5821.o ) T5821.hs:10:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case cobox_ang of _ [Occ=Dead] { GHC.Types.Eq# cobox -> (foo @ Int $dNum_anf) `cast` (_R -> Sub cobox :: (Int -> T Int) ~R# (Int -> Bool)) } Orig lhs: case cobox_ang of cobox_ang { GHC.Types.Eq# cobox -> (foo @ Int $dNum_anf) `cast` (_R -> Sub cobox :: (Int -> T Int) ~R# (Int -> Bool)) } }}} Due to commit b34068144ec3d7bfe4279b16ad16d54dd46f1c5a: {{{ Author: Simon Peyton Jones <> Date: Thu Mar 13 08:36:28 2014 +0000 A bit more tracing to do with SPECIALISE pragmas }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 02:10:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 02:10:55 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.10ae0c7a2b2c78dce9c845c3b5afc220@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: gcampax Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D524 | -------------------------------------+------------------------------------- Comment (by gcampax): nofib results from patch in D524: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna -0.0% 0.0% 0.107 0.107 0.0% ansi -0.1% 0.0% 0.000 0.000 0.0% atom -0.1% 0.0% -3.6% -3.6% 0.0% awards -0.0% 0.0% 0.000 0.000 0.0% banner -0.1% 0.0% 0.000 0.000 0.0% bernouilli -0.1% 0.0% -1.2% -1.2% 0.0% binary-trees -0.1% 0.0% -4.6% -4.6% 0.0% boyer -0.1% 0.0% 0.046 0.046 0.0% boyer2 -0.1% 0.0% 0.009 0.009 0.0% bspt -0.0% 0.0% 0.010 0.010 0.0% cacheprof -0.0% -0.3% +0.2% +0.2% +3.5% calendar -0.0% 0.0% 0.000 0.000 0.0% cichelli -0.1% 0.0% 0.088 0.088 +3.2% circsim -0.1% 0.0% -1.0% -1.0% 0.0% clausify -0.1% 0.0% 0.041 0.040 0.0% comp_lab_zift -0.1% 0.0% -2.0% -1.9% 0.0% compress -0.1% 0.0% 0.189 0.189 0.0% compress2 -0.1% 0.0% 0.173 0.173 0.0% constraints -0.1% 0.0% -6.0% -6.0% 0.0% cryptarithm1 -0.1% 0.0% -0.4% -0.3% 0.0% cryptarithm2 -0.1% 0.0% 0.011 0.011 0.0% cse -0.1% 0.0% 0.002 0.002 0.0% eliza -0.1% 0.0% 0.001 0.001 0.0% event -0.1% 0.0% 0.153 0.153 0.0% exp3_8 -0.1% 0.0% -1.4% -1.4% 0.0% expert -0.0% 0.0% 0.000 0.000 0.0% fannkuch-redux -0.1% 0.0% +0.6% +0.6% 0.0% fasta -0.0% 0.0% +0.1% +0.2% 0.0% fem -0.1% 0.0% 0.024 0.024 0.0% fft -0.0% 0.0% 0.034 0.034 0.0% fft2 -0.0% 0.0% 0.049 0.049 0.0% fibheaps -0.1% 0.0% 0.030 0.030 0.0% fish -0.1% 0.0% 0.013 0.013 0.0% fluid -0.0% 0.0% 0.010 0.010 0.0% fulsom -0.1% 0.0% -5.5% -5.5% 0.0% gamteb -0.1% 0.0% 0.042 0.042 0.0% gcd -0.1% 0.0% 0.048 0.048 0.0% gen_regexps -0.1% 0.0% 0.000 0.000 0.0% genfft -0.1% 0.0% 0.035 0.035 0.0% gg -0.0% 0.0% 0.011 0.011 0.0% grep -0.0% 0.0% 0.000 0.000 0.0% hidden -0.1% 0.0% -9.1% -9.0% 0.0% hpg -0.1% 0.0% 0.114 0.114 0.0% ida -0.1% 0.0% 0.090 0.090 0.0% infer -0.1% 0.0% 0.052 0.052 0.0% integer -0.1% 0.0% +0.9% +1.0% 0.0% integrate -0.1% 0.0% 0.121 0.121 0.0% k-nucleotide -0.0% 0.0% -10.8% -10.8% 0.0% kahan -0.0% 0.0% +0.1% +0.1% 0.0% knights -0.1% 0.0% 0.005 0.005 0.0% lcss -0.1% 0.0% -6.8% -6.8% 0.0% life -0.1% 0.0% -4.1% -4.0% 0.0% lift -0.0% 0.0% 0.002 0.002 0.0% listcompr -0.1% 0.0% 0.101 0.101 0.0% listcopy -0.1% 0.0% 0.107 0.107 0.0% maillist -0.1% 0.0% 0.060 0.060 +2.2% mandel -0.0% 0.0% 0.077 0.077 0.0% mandel2 -0.1% 0.0% 0.004 0.004 0.0% minimax -0.0% 0.0% 0.003 0.003 0.0% mkhprog -0.1% 0.0% 0.003 0.003 0.0% multiplier -0.1% 0.0% 0.147 0.147 0.0% n-body -0.1% 0.0% +1.5% +1.5% 0.0% nucleic2 -0.1% 0.0% 0.068 0.068 0.0% para -0.1% 0.0% +1.6% +1.5% 0.0% paraffins -0.1% 0.0% 0.112 0.112 0.0% parser -0.1% 0.0% 0.030 0.030 0.0% parstof -0.1% 0.0% 0.006 0.006 0.0% pic -0.1% 0.0% 0.007 0.007 0.0% pidigits -0.1% 0.0% -0.1% -0.0% 0.0% power -0.1% 0.0% -7.8% -7.8% 0.0% pretty -0.1% 0.0% 0.000 0.000 0.0% primes -0.1% 0.0% 0.070 0.070 0.0% primetest -0.1% 0.0% 0.130 0.130 0.0% prolog -0.1% 0.0% 0.002 0.002 0.0% puzzle -0.1% 0.0% 0.148 0.148 0.0% queens -0.1% 0.0% 0.015 0.015 0.0% reptile -0.1% 0.0% 0.011 0.011 0.0% reverse-complem -0.1% 0.0% 0.117 0.117 0.0% rewrite -0.1% 0.0% 0.018 0.018 0.0% rfib -0.1% 0.0% 0.020 0.020 0.0% rsa -0.1% 0.0% 0.028 0.028 0.0% scc -0.1% 0.0% 0.000 0.000 0.0% sched -0.1% 0.0% 0.023 0.023 0.0% scs -0.0% 0.0% -2.4% -2.5% 0.0% simple -0.0% 0.0% -2.7% -2.7% 0.0% solid -0.1% 0.0% 0.154 0.154 0.0% sorting -0.1% 0.0% 0.002 0.002 0.0% spectral-norm -0.1% 0.0% -0.0% -0.0% 0.0% sphere -0.1% 0.0% 0.053 0.053 0.0% symalg -0.1% 0.0% 0.015 0.015 0.0% tak -0.1% 0.0% 0.016 0.016 0.0% transform -0.1% 0.0% -1.2% -1.1% 0.0% treejoin -0.1% 0.0% 0.144 0.144 0.0% typecheck -0.1% 0.0% -13.9% -13.8% 0.0% veritas -0.0% 0.0% 0.002 0.002 0.0% wang -0.1% 0.0% 0.119 0.119 0.0% wave4main -0.1% 0.0% -3.4% -3.4% 0.0% wheel-sieve1 -0.1% 0.0% -0.3% -0.4% 0.0% wheel-sieve2 -0.1% 0.0% -2.8% -2.8% 0.0% x2n1 -0.1% 0.0% 0.005 0.005 0.0% -------------------------------------------------------------------------------- Min -0.1% -0.3% -13.9% -13.8% 0.0% Max -0.0% 0.0% +1.6% +1.5% +3.5% Geometric Mean -0.1% -0.0% -2.9% -2.9% +0.1% }}} I think it's also significant to look at GC elapsed time: {{{ ------------------------------------------------------------------------------- Program nofib-log-old nofib-log-new ------------------------------------------------------------------------------- anna 0.025 0.024 ansi 0.000 0.000 atom 0.283 -6.4% awards 0.000 0.000 banner 0.000 0.000 bernouilli 0.075 0.072 binary-trees 0.323 -6.6% boyer 0.023 0.021 boyer2 0.004 0.003 bspt 0.005 0.005 cacheprof 0.145 0.143 calendar 0.000 0.000 cichelli 0.017 0.016 circsim 0.577 -6.3% clausify 0.015 0.013 comp_lab_zift 0.098 0.094 compress 0.082 0.079 compress2 0.145 0.140 constraints 2.335 -8.8% cryptarithm1 0.022 0.021 cryptarithm2 0.001 0.001 cse 0.001 0.001 eliza 0.000 0.000 event 0.088 0.082 exp3_8 0.039 0.037 expert 0.000 0.000 fannkuch-redux 0.007 0.007 fasta 0.004 0.004 fem 0.006 0.006 fft 0.023 0.022 fft2 0.019 0.018 fibheaps 0.013 0.012 fish 0.001 0.001 fluid 0.002 0.002 fulsom 0.205 -7.4% gamteb 0.009 0.009 gcd 0.001 0.001 gen_regexps 0.000 0.000 genfft 0.015 0.014 gg 0.005 0.005 grep 0.000 0.000 hidden 0.022 0.021 hpg 0.018 0.017 ida 0.028 0.027 infer 0.026 0.024 integer 0.025 0.024 integrate 0.002 0.002 k-nucleotide 0.025 0.024 kahan 0.001 0.000 knights 0.001 0.001 lcss 0.359 -8.8% life 0.155 0.143 lift 0.000 0.001 listcompr 0.005 0.005 listcopy 0.006 0.005 maillist 0.013 0.012 mandel 0.004 0.004 mandel2 0.001 0.001 minimax 0.001 0.001 mkhprog 0.001 0.001 multiplier 0.042 0.039 n-body 0.009 0.009 nucleic2 0.005 0.004 para 0.095 0.088 paraffins 0.099 0.091 parser 0.012 0.011 parstof 0.002 0.002 pic 0.004 0.004 pidigits 0.044 0.043 power 0.282 -11.9% pretty 0.000 0.000 primes 0.023 0.021 primetest 0.002 0.002 prolog 0.001 0.001 puzzle 0.019 0.018 queens 0.000 0.000 reptile 0.005 0.004 reverse-complem 0.001 0.001 rewrite 0.001 0.001 rfib 0.000 0.000 rsa 0.001 0.001 scc 0.000 0.000 sched 0.002 0.002 scs 0.243 -6.2% simple 0.081 0.074 solid 0.087 0.080 sorting 0.001 0.001 spectral-norm 0.000 0.000 sphere 0.005 0.005 symalg 0.001 0.001 tak 0.000 0.000 transform 0.095 0.089 treejoin 0.092 0.087 typecheck 0.013 0.012 veritas 0.001 0.001 wang 0.090 0.087 wave4main 0.118 0.110 wheel-sieve1 0.031 0.029 wheel-sieve2 0.165 0.159 x2n1 0.000 0.000 -1 s.d. ----- -9.7% +1 s.d. ----- -5.9% Average ----- -7.8% }}} Results are comparing 4897e7 (up to date master) with a2de1f (the patch), on a 16 core Intel Xeon 2.40GHz, 48GB RAM total, no swap, overcommit_memory = 0 (the default), on a x86_64 Linux 3.12.9 It would be interesting to see why certain programs are regressing. They seem to be multithreaded programs, so it could be that we're spending more time in the memory allocator, which is locked and kills multithreading. Or it could be that they trigger pessimal allocator behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 02:15:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 02:15:34 -0000 Subject: [GHC] #5780: -faggressive-primops change caused a failure in perf/compiler/parsing001 In-Reply-To: <047.05534318ff82e497bc532f3218df00c5@haskell.org> References: <047.05534318ff82e497bc532f3218df00c5@haskell.org> Message-ID: <062.52dc65ca9c06317202cc1835a0dd5661@haskell.org> #5780: -faggressive-primops change caused a failure in perf/compiler/parsing001 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: SPJ: this ticket does not appear on your [wiki:Status/SLPJ-Tickets list]. Should it stay open? The reverted commit would need some work to make it compatible with HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 02:35:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 02:35:19 -0000 Subject: [GHC] #5763: Confusing error message In-Reply-To: <046.5a7a33b05ac2f5577fdef291d8adb62b@haskell.org> References: <046.5a7a33b05ac2f5577fdef291d8adb62b@haskell.org> Message-ID: <061.9c71c6f1ceb6670978cd25a49d33d23d@haskell.org> #5763: Confusing error message -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: indexed- | types/should_fail/T5763 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Is this problem solved? `T4272` doesn't show the `Occurs check` message anymore (as also noted by SPJ in da71a9524ffff0865222127bef09fd04a1359a53), but maybe this is incidental? I can not find test `T5763` anywhere, so I'll leave this open for now. Output of running the command "git show 0b3c3c81792c88ee40687f86bed4935e721dabe0 testsuite/tests/indexed- types/should_fail/T4272.stderr": {{{ Author: Dimitrios.Vytiniotis <> Date: Wed Apr 4 14:41:11 2012 +0100 Error message modifications following ghc-new-solver modifications diff --git a/testsuite/tests/indexed-types/should_fail/T4272.stderr b/testsuite/tests/indexed-types/should_fail/T4272.stderr index 24f0cbd..e809d9c 100644 --- a/testsuite/tests/indexed-types/should_fail/T4272.stderr +++ b/testsuite/tests/indexed-types/should_fail/T4272.stderr @@ -1,29 +1,6 @@ -T4272.hs:11:16: - Couldn't match type `TermFamily (TermFamily x0 x0)' - with `TermFamily x0' - NB: `TermFamily' is a type function, and may not be injective - The type variable `x0' is ambiguous - Possible fix: add a type signature that fixes these type variable(s) - Expected type: TermFamily x0 x0 - Actual type: TermFamily a a - In the first argument of `prune', namely `t' - In the expression: prune t (terms (undefined :: TermFamily a a)) - In an equation for `laws': - laws t = prune t (terms (undefined :: TermFamily a a)) - -T4272.hs:11:16: - Occurs check: cannot construct the infinite type: - x0 = TermFamily x0 x0 - Expected type: TermFamily x0 x0 - Actual type: TermFamily a a - In the first argument of `prune', namely `t' - In the expression: prune t (terms (undefined :: TermFamily a a)) - In an equation for `laws': - laws t = prune t (terms (undefined :: TermFamily a a)) - -T4272.hs:11:19: - Could not deduce (a ~ TermFamily x0 x0) +T4272.hs:11:26: + Could not deduce (a ~ TermFamily a a) from the context (TermLike a) bound by the type signature for laws :: TermLike a => TermFamily a a -> b @@ -31,7 +8,10 @@ T4272.hs:11:19: `a' is a rigid type variable bound by the type signature for laws :: TermLike a => TermFamily a a -> b at T4272.hs:10:16 - In the return type of a call of `terms' + Expected type: TermFamily a (TermFamily a a) + Actual type: TermFamily a a + In the first argument of `terms', namely + `(undefined :: TermFamily a a)' In the second argument of `prune', namely `(terms (undefined :: TermFamily a a))' In the expression: prune t (terms (undefined :: TermFamily a a)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 02:39:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 02:39:14 -0000 Subject: [GHC] #5757: zero unexpected failures on all tier 1 platforms In-Reply-To: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> References: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> Message-ID: <062.f21b309aa04ac213e489d5433168107a@haskell.org> #5757: zero unexpected failures on all tier 1 platforms -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9389 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #5785 => #9389 Comment: This is still a noble goal. See also #9389 for OS X testsuite failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 02:42:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 02:42:23 -0000 Subject: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched In-Reply-To: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> References: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> Message-ID: <057.2e2467bbfa5c07d1a52cfaa3b1957454@haskell.org> #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.1 Resolution: | Keywords: warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): This must have been fixed in the 7.8 release series. Only a regression test is missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 03:07:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 03:07:16 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.480fc99621d1c4c01a4992a13a7ba8ad@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | profiling/should_run/scc004 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * difficulty: => Unknown Comment: The results with HEAD are both different from "what we want" and "what we get". What are we aiming for precisely? `ghc-7.9.20141125 -prof -fforce-recomp test.hs; ./test +RTS -p` {{{ MAIN MAIN 43 0 0.0 22.2 0.0 100.0 CAF Main 85 0 0.0 0.1 0.0 0.1 g Main 87 1 0.0 0.0 0.0 0.0 f Main 86 1 0.0 0.0 0.0 0.0 }}} And with `-O2`: {{{ MAIN MAIN 43 0 0.0 22.2 0.0 100.0 CAF Main 85 0 0.0 0.1 0.0 0.1 g Main 87 1 0.0 0.0 0.0 0.0 f Main 86 1 0.0 0.0 0.0 0.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 03:26:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 03:26:06 -0000 Subject: [GHC] #5641: The -L flag should not exist In-Reply-To: <047.46e72104686b8a69940a4b2fea73bf01@haskell.org> References: <047.46e72104686b8a69940a4b2fea73bf01@haskell.org> Message-ID: <062.bbb84ddb43a7dc62026e2cac27f4f7c8@haskell.org> #5641: The -L flag should not exist -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: 3024 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * blockedby: 3024, 3024 => 3024 Comment: For reference, in commit 16871485a44ba8a6e93e40f30af7ea46839e0c4c: {{{ Author: Ravi Nanavati <> Date: Fri Sep 29 22:51:15 2006 +0000 rts_ccs_length Add the -L RTS flag to control the length of the cost-centre stacks reported in a heap profile. }}} And in `rts/RtsFlags.c`: {{{ " -L Maximum length of a cost-centre stack in a heap profile", " (default: 25)", }}} Undocument as far as I can tell in the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime- control.html user's guide]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 03:36:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 03:36:22 -0000 Subject: [GHC] #5608: Fix T3807 for Mac OS X 10.5 In-Reply-To: <050.e84523bb4f6c3af12c04790171cc1f54@haskell.org> References: <050.e84523bb4f6c3af12c04790171cc1f54@haskell.org> Message-ID: <065.789f124552c08376885c85432e9994ef@haskell.org> #5608: Fix T3807 for Mac OS X 10.5 --------------------------------------+--------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Test Suite | Version: 7.3 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | --------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Test T3807 is passing on OS X, probably thanks to using the [wiki:DynamicGhcPrograms system linker] since 7.8.1, so this patch is no longer needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 03:37:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 03:37:25 -0000 Subject: [GHC] #5608: Fix T3807 for Mac OS X 10.5 In-Reply-To: <050.e84523bb4f6c3af12c04790171cc1f54@haskell.org> References: <050.e84523bb4f6c3af12c04790171cc1f54@haskell.org> Message-ID: <065.5186483e80e5cafbeedaf2ce53c6ef49@haskell.org> #5608: Fix T3807 for Mac OS X 10.5 --------------------------------------+--------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Test Suite | Version: 7.3 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | --------------------------------------+--------------------------- Comment (by thomie): See also #9389 for the list of current failures on OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 04:15:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 04:15:23 -0000 Subject: [GHC] #9837: Introduce a logging API to GHC In-Reply-To: <047.adb1a804fb52c7dc4c827ad80fa6f2c8@haskell.org> References: <047.adb1a804fb52c7dc4c827ad80fa6f2c8@haskell.org> Message-ID: <062.508c912ccee031f138d2ebe56114e29e@haskell.org> #9837: Introduce a logging API to GHC -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Can you describe an intended consumer of such a log? To my knowledge, there is no centralized logging structure, per se, although there are plenty of `-d` flags that dump log-like output. There is some central management of these flags, but I don't think there's a ton of consistency about this. However, before trying to shore this up, it would be helpful to know what a consumer would look like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 04:25:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 04:25:25 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.bd536c93715aea4e89c34452f7938902@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Here's a test case for the !ConstraintKinds problem: {{{ {-# LANGUAGE ConstraintKinds #-} module A where type EqShow a = (Eq a, Show a) }}} {{{ module B where import A foo :: EqShow a => a -> String foo x = show x ++ show (x == x) }}} Compiling yields {{{ B.hs:5:8: Illegal tuple constraint: EqShow a (Use ConstraintKinds to permit this) In the type signature for ?foo?: foo :: EqShow a => a -> String }}} I'd love to see this fix get in for 7.10, but I won't have a chance to work on this before the (new) freeze date on Friday. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 05:18:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 05:18:03 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.a280cca56c1bba0760eaeba23c9e57a9@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): What modules would need be touched to get that in for 7.10? (if its not too deep a dive, i can try to make time tomorrow?) Theres some refinements Ed still wants me to do on the prefetch work, but I think he and i would both agree that getting this into 7.10 has greater impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 06:14:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 06:14:17 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.35f065bae2343cf206453c9945aa888c@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): >OK -- so it seems you want to be able to fuzz the */Constraint distinction. Sorta, yeah. More like having a data type of existential functions. I'm actually trying to work towards local instances (or at least, better library support for approximations of it like reflection). As such it is inappropriate for TH. Additionally, I wish for it to run on platforms without TH, such as ARM. I'm not really proposing a general language feature, but rather, allowing typesafe access to desugared syntax; any high level language design would almost certainly need access to it anyway, so this would be laying the foundation for experimentation in that area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 06:20:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 06:20:30 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.40b33fc22ab0ace4e3a5a55006b45aca@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): It seems like the converse of that thread though - it's more wanting to be able to say "use this dictionary to evaluate this function" without having to manually create a new datatype etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 11:23:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 11:23:28 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.8c96e237ecd69d76842da7dd227a9b93@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"d8c437b37436e150986a7607f574ac2c3a604f40/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d8c437b37436e150986a7607f574ac2c3a604f40" Don't require PatternSynonyms language extension to just use pattern synonyms (see #9838) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 11:24:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 11:24:19 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.87037e5966b55525d8d8e7083719a34b@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): I've removed the need for turning on `PatternSynonyms` just to use pattern synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 13:09:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 13:09:34 -0000 Subject: [GHC] #9839: RTS options parser silently accepts invalid flags Message-ID: <049.1ac180907787acdf75c140998b5b4263@haskell.org> #9839: RTS options parser silently accepts invalid flags -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: #4243 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- RTS options that do not take arguments (such as `-T`) silently ignore anything that comes afterwards. For example, `+RTS -T,-s` or `+RTS -T-s` turns on collection of GC statistics (`-T`) but does not print out a summary (`-s`). Instead, this should produce an error message. Otherwise, users may mistakenly think that options have been applied. (This has just bitten us in a production system.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 13:22:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 13:22:00 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.e6033d47f407eb99059fc358b4627d71@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 6.13 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9839 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * related: => #9839 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 13:52:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 13:52:33 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.1492ef90de43034f04268cee8382f9dc@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8731 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:05:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:05:00 -0000 Subject: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched In-Reply-To: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> References: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> Message-ID: <057.ea91dbb9ee35a243f680fc0bc7f6f3e8@haskell.org> #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.1 Resolution: | Keywords: warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: george.karachalias@?, tom.schrijvers@? (added) Comment: Actually not. The warning was being suppressed by {{{ handleWarnings = if isGenerated origin then discardWarningsDs else id }}} in `matchWrapper`, which is really intended to suppress warnings in code generate by `deriving` etc. I've fixed this which makes the warning come back. It's really is part of the pattern-match-fixup problem. Fortunately, Geroge K and Tom S are working on this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:09:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:09:02 -0000 Subject: [GHC] #5763: Confusing error message In-Reply-To: <046.5a7a33b05ac2f5577fdef291d8adb62b@haskell.org> References: <046.5a7a33b05ac2f5577fdef291d8adb62b@haskell.org> Message-ID: <061.58edb3323b4875bbe90b542458240451@haskell.org> #5763: Confusing error message -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: indexed-types/should_fail/T5763 => * resolution: => fixed Comment: Well we indeed no longer use insoluble constraints to rewrite others, so yes, I think we can close this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:10:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:10:50 -0000 Subject: [GHC] #5780: -faggressive-primops change caused a failure in perf/compiler/parsing001 In-Reply-To: <047.05534318ff82e497bc532f3218df00c5@haskell.org> References: <047.05534318ff82e497bc532f3218df00c5@haskell.org> Message-ID: <062.2a66ed697dac71b4fb2e4f318a08251b@haskell.org> #5780: -faggressive-primops change caused a failure in perf/compiler/parsing001 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes I think it should stay open. I've forgotten the context to be honest. I'll add it to my list! (But I don't expect to pay attention to it for some time, so others feel free to grab it.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:12:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:12:48 -0000 Subject: [GHC] #9840: Permit empty closed type families Message-ID: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment, closed type families without any equations fail with a parse error. In addition, they cannot be created by TH (see #8028). Would it be possible to permit these instead? My use case is in my typechecker plugin for units of measure, where I want to add new type-level operators without any equational theory (because it will be supplied by the plugin) and without users having the ability to introduce their own type family instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:16:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:16:53 -0000 Subject: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched In-Reply-To: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> References: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> Message-ID: <057.059c0c89e155de3354375b20edc49cfa@haskell.org> #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.1 Resolution: | Keywords: warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Also you need `-fwarn-incomplete-record-updates` to see the warning; for some reason this flag is explicitly not in `-Wall` according to the user manual. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:23:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:23:34 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.479b0550503aa87ac4c233d87abaa1ae@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | patsyn/should_compile/ImpExp_Imp, | polykinds/T9838 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_compile/ImpExp_Imp, polykinds/T9838 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:24:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:24:33 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.f35e3462e8eddfc6520dbc98bc942630@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | patsyn/should_compile/ImpExp_Imp, | polykinds/T9838 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"417b8746b9d3759a102160c4db882b18ac658a0e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="417b8746b9d3759a102160c4db882b18ac658a0e" Don't require ConstraintKinds at usage sites (Trac #9838) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:24:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:24:33 -0000 Subject: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched In-Reply-To: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> References: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> Message-ID: <057.a274722c6241a70b5f0033fcb5520f88@haskell.org> #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.1 Resolution: | Keywords: warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a67ebbecfb10c91bb2793cb2f7d91f25aa23e493/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a67ebbecfb10c91bb2793cb2f7d91f25aa23e493" Resume reporting incomplete pattern matches for record updates They were being inadvertently suppressed, even if you said -fwarn- incomplete-record-updates See Trac #5728 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:26:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:26:22 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.9b967086296469171d2d736b5c9fb928@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): But you also want them to be non injective? Otherwise you could say {{{ data Plus a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:27:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:27:26 -0000 Subject: [GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. In-Reply-To: <045.0b65349f28e5656b4f336583aec26453@haskell.org> References: <045.0b65349f28e5656b4f336583aec26453@haskell.org> Message-ID: <060.d22de81943d51133e947f2facab5f57e@haskell.org> #9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | patsyn/should_compile/ImpExp_Imp, | polykinds/T9838 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Good. Done. Tests added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:32:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:32:25 -0000 Subject: [GHC] #6022: GHC infers over-general types In-Reply-To: <046.17a0376aec11ac55102e23a3c30540d1@haskell.org> References: <046.17a0376aec11ac55102e23a3c30540d1@haskell.org> Message-ID: <061.bd0076796d9bb27b41e415ae403d7060@haskell.org> #6022: GHC infers over-general types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8883 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4721167a0118e4c8bc6c8266c3357a8a2ac4f4e2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4721167a0118e4c8bc6c8266c3357a8a2ac4f4e2" Trac #6022 is actually fine now }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 14:33:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 14:33:02 -0000 Subject: [GHC] #6022: GHC infers over-general types In-Reply-To: <046.17a0376aec11ac55102e23a3c30540d1@haskell.org> References: <046.17a0376aec11ac55102e23a3c30540d1@haskell.org> Message-ID: <061.77faed7632469c55115c3bc46721b9de@haskell.org> #6022: GHC infers over-general types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8883 Test Case: | typecheck/should_fail/T6022 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T6022 Comment: And the test was actually there, just marked as broken! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 15:07:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 15:07:22 -0000 Subject: [GHC] #9839: RTS options parser silently accepts invalid flags In-Reply-To: <049.1ac180907787acdf75c140998b5b4263@haskell.org> References: <049.1ac180907787acdf75c140998b5b4263@haskell.org> Message-ID: <064.3c877b7f081cdc05c0831865cf63e12f@haskell.org> #9839: RTS options parser silently accepts invalid flags -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: #4243 result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 15:28:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 15:28:00 -0000 Subject: [GHC] #7277: Recompilation check fails for TH unless functions are inlined In-Reply-To: <050.603d1a84b9f7903399d4601701fdbcaa@haskell.org> References: <050.603d1a84b9f7903399d4601701fdbcaa@haskell.org> Message-ID: <065.f62c007557243fb00c0df4ad5384ae18@haskell.org> #7277: Recompilation check fails for TH unless functions are inlined -------------------------------------+------------------------------------- Reporter: | Owner: orenbenkiki | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 481 Type of failure: Incorrect | result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 15:43:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 15:43:32 -0000 Subject: [GHC] #7243: regression: acceptable foreign result types In-Reply-To: <044.20527182530838d815e1a65c339ea3b9@haskell.org> References: <044.20527182530838d815e1a65c339ea3b9@haskell.org> Message-ID: <059.ae0792ca1600cd5eed4c4aaf51adec1f@haskell.org> #7243: regression: acceptable foreign result types -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (FFI) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b61091d3b042305ce21bb00b28a81f903b522394/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b61091d3b042305ce21bb00b28a81f903b522394" Test Trac #7243 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 15:43:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 15:43:32 -0000 Subject: [GHC] #9830: Standalone-derived Show instance for type constructor has different precedence if orphan instance In-Reply-To: <050.5a294db69b3f4b3a7a91abd307a8c2ef@haskell.org> References: <050.5a294db69b3f4b3a7a91abd307a8c2ef@haskell.org> Message-ID: <065.3c2f14dab56f7f2fc144aa3e87e71ca3@haskell.org> #9830: Standalone-derived Show instance for type constructor has different precedence if orphan instance -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"01f03cb30426fad1b848051fa142c04c8816a80c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="01f03cb30426fad1b848051fa142c04c8816a80c" Get the right fixity-env in standalone deriving (Trac #9830) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 15:55:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 15:55:26 -0000 Subject: [GHC] #9808: Add data-dir to InstalledPackageInfo In-Reply-To: <044.d7df9b805388be68f8a820b34b606910@haskell.org> References: <044.d7df9b805388be68f8a820b34b606910@haskell.org> Message-ID: <059.b189ecddfbfba6e8d63987bead558e26@haskell.org> #9808: Add data-dir to InstalledPackageInfo -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Package | Version: 7.8.3 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D499 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: Since Phab:D499 was abandoned, and Phab:D514 accepted, can this ticket be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 16:28:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 16:28:25 -0000 Subject: [GHC] #9830: Standalone-derived Show instance for type constructor has different precedence if orphan instance In-Reply-To: <050.5a294db69b3f4b3a7a91abd307a8c2ef@haskell.org> References: <050.5a294db69b3f4b3a7a91abd307a8c2ef@haskell.org> Message-ID: <065.13f5d998389eeaa6d041c2e8d5b21995@haskell.org> #9830: Standalone-derived Show instance for type constructor has different precedence if orphan instance -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | deriving/should_run/T9830 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => deriving/should_run/T9830 * resolution: => fixed Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 16:29:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 16:29:16 -0000 Subject: [GHC] #7243: regression: acceptable foreign result types In-Reply-To: <044.20527182530838d815e1a65c339ea3b9@haskell.org> References: <044.20527182530838d815e1a65c339ea3b9@haskell.org> Message-ID: <059.ada5d5874c1d62630ddd542023d0ce86@haskell.org> #7243: regression: acceptable foreign result types -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (FFI) | Keywords: Resolution: fixed | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | ffi/should_fail/T7243 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ffi/should_fail/T7243 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 16:41:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 16:41:28 -0000 Subject: [GHC] #9841: Touching a file that uses TH triggers TH recompilation flood Message-ID: <042.a8778786cec9a1cfbb06d527a298d097@haskell.org> #9841: Touching a file that uses TH triggers TH recompilation flood -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: #481, #7277 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Check out this test case: https://github.com/nh2/ghc-th-recomp-touch-test I have 2 modules, A and B, both using TH (using aeson) with B importing A. After the first compilation, `touch A.hs && ghc --make B.hs` causes B to be recompiled. Why should this be the case? If we see that the A.hi file is completely identical with what it was before, why should we recompile B? This problem actually hits pretty hard when working in projects with > 200 modules. (This all is under the assumption that TH doesn't do any IO with observably different result; we do already have this assumption if I understand it correctly, since otherwise we would always recompile all TH code, which we don't.) ---- Another problem is that the process is not very repeatable: If you do `touch A.hs && ghc --make All.hs` and hit `Ctrl-C` before everything is done (e.g. after the 3rd modules), and then run just `ghc --make All.hs`, then GHC will decide to compile nothing at all, even though it had determined just before that everything needs to be recompiled. Is this expected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 16:46:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 16:46:33 -0000 Subject: [GHC] #9736: Constant folding rules are wrong for GHCJS In-Reply-To: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> References: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> Message-ID: <059.c2bfcc775869c8e2fa8a3c3cac89422e@haskell.org> #9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D502 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Please re-open if the work here is not done yet; I can't tell with certainty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 16:54:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 16:54:54 -0000 Subject: [GHC] #9757: Warn about derivable instances In-Reply-To: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> References: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> Message-ID: <060.d326d2f4a7f048de881dbb5d1b4330a2@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: Sorry David. Neil is usually very responsive to [https://github.com/ndmitchell/hlint issues and pull requests] though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 17:04:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 17:04:07 -0000 Subject: [GHC] #9842: No Typeable instance for type-level literals Message-ID: <048.436196530b929cc40e1e890324e0317c@haskell.org> #9842: No Typeable instance for type-level literals -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There's no Typeable instance for string and numeric literals. E.g. {{{ Prelude GHC.TypeLits Data.Typeable> typeRep (Proxy :: Proxy "foo") :15:1: No instance for (Typeable "foo") arising from a use of ?typeRep? In the expression: typeRep (Proxy :: Proxy "foo") In an equation for ?it?: it = typeRep (Proxy :: Proxy "foo") }}} This means that we can't have a Typeable instance for phantom types parameterised by these literals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 17:10:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 17:10:01 -0000 Subject: [GHC] #9842: No Typeable instance for type-level literals In-Reply-To: <048.436196530b929cc40e1e890324e0317c@haskell.org> References: <048.436196530b929cc40e1e890324e0317c@haskell.org> Message-ID: <063.45bb7547ad8ea289f47fac15e34703e1@haskell.org> #9842: No Typeable instance for type-level literals -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8778 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #8778 Comment: In commit 0354fb3676e5b0044601c8e0a5f8039f0cac0c8d: {{{ Author: Iavor S. Diatchki Date: Sat Jun 14 14:08:23 2014 -0700 Implement `Typeable` support for type-level literals (#8778). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 17:17:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 17:17:12 -0000 Subject: [GHC] #9842: No Typeable instance for type-level literals and promoted types (was: No Typeable instance for type-level literals) In-Reply-To: <048.436196530b929cc40e1e890324e0317c@haskell.org> References: <048.436196530b929cc40e1e890324e0317c@haskell.org> Message-ID: <063.f08d2cd9652cc38822b9d9f579533eac@haskell.org> #9842: No Typeable instance for type-level literals and promoted types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8778 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by Feuerbach: Old description: > There's no Typeable instance for string and numeric literals. E.g. > > {{{ > Prelude GHC.TypeLits Data.Typeable> typeRep (Proxy :: Proxy "foo") > > :15:1: > No instance for (Typeable "foo") arising from a use of ?typeRep? > In the expression: typeRep (Proxy :: Proxy "foo") > In an equation for ?it?: it = typeRep (Proxy :: Proxy "foo") > }}} > > This means that we can't have a Typeable instance for phantom types > parameterised by these literals. New description: There's no Typeable instance for string and numeric literals. E.g. {{{ Prelude GHC.TypeLits Data.Typeable> typeRep (Proxy :: Proxy "foo") :15:1: No instance for (Typeable "foo") arising from a use of ?typeRep? In the expression: typeRep (Proxy :: Proxy "foo") In an equation for ?it?: it = typeRep (Proxy :: Proxy "foo") }}} This means that we can't have a Typeable instance for phantom types parameterised by these literals. Ditto for the promoted data types: {{{ Prelude Data.Typeable> typeRep (Proxy :: Proxy Nothing) :4:1: No instance for (Typeable 'Nothing) arising from a use of ?typeRep? In the expression: typeRep (Proxy :: Proxy Nothing) In an equation for ?it?: it = typeRep (Proxy :: Proxy Nothing) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 17:18:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 17:18:33 -0000 Subject: [GHC] #9842: No Typeable instance for type-level literals and promoted types In-Reply-To: <048.436196530b929cc40e1e890324e0317c@haskell.org> References: <048.436196530b929cc40e1e890324e0317c@haskell.org> Message-ID: <063.af676cc920887de073e800624495a537@haskell.org> #9842: No Typeable instance for type-level literals and promoted types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8778 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Thanks thomie. Is the second part fixed as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 17:22:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 17:22:52 -0000 Subject: [GHC] #9842: No Typeable instance for type-level literals and promoted types In-Reply-To: <048.436196530b929cc40e1e890324e0317c@haskell.org> References: <048.436196530b929cc40e1e890324e0317c@haskell.org> Message-ID: <063.dd0a985cebe8e83b3b80e1c7867a2839@haskell.org> #9842: No Typeable instance for type-level literals and promoted types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8778 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Yes, it will be in 7.10: {{{ Prelude Data.Typeable> typeRep (Proxy :: Proxy Nothing) Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 17:56:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 17:56:17 -0000 Subject: [GHC] #5537: ghc doesn't find libffi.so.5 in testsuite In-Reply-To: <056.82b7c5128f5c80c0242160041370d234@haskell.org> References: <056.82b7c5128f5c80c0242160041370d234@haskell.org> Message-ID: <071.88e0f682e548ca062292249e05ea72e3@haskell.org> #5537: ghc doesn't find libffi.so.5 in testsuite -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: closed Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.3 Component: Test Suite | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Running the testsuite the `dyn` way should work now, but please re-open if this is still an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 17:56:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 17:56:45 -0000 Subject: [GHC] #5537: ghc doesn't find libffi.so.5 in testsuite In-Reply-To: <056.82b7c5128f5c80c0242160041370d234@haskell.org> References: <056.82b7c5128f5c80c0242160041370d234@haskell.org> Message-ID: <071.918c07556d0efe65ec8c5a372b53d54d@haskell.org> #5537: ghc doesn't find libffi.so.5 in testsuite -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: closed Type: bug | Milestone: Priority: low | Version: 7.3 Component: Test Suite | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 18:57:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 18:57:04 -0000 Subject: [GHC] #5522: mc03 -O -fliberate-case -fspec-constr runs out of memory In-Reply-To: <044.70b406220a8f6320743e1c51e2eba565@haskell.org> References: <044.70b406220a8f6320743e1c51e2eba565@haskell.org> Message-ID: <059.0d1789eec0b120762190cb71029f4c4c@haskell.org> #5522: mc03 -O -fliberate-case -fspec-constr runs out of memory -------------------------------------+------------------------------------- Reporter: btutt | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: mc03 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * os: Windows => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: The immediate issue here is fixed. Test `5522.hs` from comment:2 does not run out of memory anymore. The reason seems to be that HEAD now reduces ''monad'' comprehensions such as `[x0 + x1 | x0 <- [0], x1 <- [1]]` to just `[1]` at compile time, just as 7.8.3 and earlier already did with ''list'' comprehensions. Maybe the real bug is just covered up? This is the output of `ghc -fforce-recomp --make 5522.hs -O -fliberate-case -fspec-constr -ddump-simpl`: {{{ ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 7, types: 5, coercions: 0} Foo.output1 :: Int [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Foo.output1 = GHC.Types.I# 450 output :: [Int] [GblId, Caf=NoCafRefs, Str=DmdType m2, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] output = GHC.Types.: @ Int Foo.output1 (GHC.Types.[] @ Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 20:42:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 20:42:31 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.460ea1d9413bf89999b97a2bb8044eb3@haskell.org> #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by JeanPhilippeMoresmau): I have a similar problem. Using 7.8.3 on Ubuntu, evaluating an expression using the GHC API works if the executable is build with -dynamic, and fails with a segFault if it's build statically. Should I create a new ticket or modify this one? Since Hackage refuses packages that use the -dynamic flag because of a Cabal bug it's annoying (and -dynamic may not work on all OSes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 20:51:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 20:51:38 -0000 Subject: [GHC] #8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails In-Reply-To: <045.760cae9f013a16aed8eac702a0c53725@haskell.org> References: <045.760cae9f013a16aed8eac702a0c53725@haskell.org> Message-ID: <060.2d0215844c7cf1417f4a1d95b5e4e814@haskell.org> #8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails -------------------------------------+------------------------------------- Reporter: troydm | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by troydm): Just tested on my Solaris with ghc 7.6.3 and it's still reproduceable and I'm sure it's the same with 7.8.3 too (also unfortuneatly I don't have an Solaris box at hand with latest ghc to test it) This bug only occurs on Solaris/OpenIndiana operating system -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 20:53:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 20:53:42 -0000 Subject: [GHC] #8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails In-Reply-To: <045.760cae9f013a16aed8eac702a0c53725@haskell.org> References: <045.760cae9f013a16aed8eac702a0c53725@haskell.org> Message-ID: <060.4fc6d58ec8ffbe4f39c6834a1eac72a3@haskell.org> #8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails -------------------------------------+------------------------------------- Reporter: troydm | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by troydm): * status: infoneeded => upstream * architecture: x86 => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 21:43:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 21:43:50 -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.db27f056e001b3bdbe0efa55e9641d79@haskell.org> #5466: Documentation for Chan could be better -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core | Version: 7.2.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * difficulty: => Unknown Old description: > The summary is two words, and none of the operations say whether they > block or not. Someone on reddit was expecting a read to throw an > exception if the Chan was empty, for example. It also turns out that > isEmptyChan is deprecated, but the documentation doesn't mention it. New description: The summary is two words, and none of the operations say whether they block or not. Someone on reddit was expecting a read to throw an exception if the Chan was empty, for example. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 23:03:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 23:03:12 -0000 Subject: [GHC] #7482: GHC.Event overwrites main IO managers hooks to RTS In-Reply-To: <053.8265638cb53ac37cc1aae74a0afb4d97@haskell.org> References: <053.8265638cb53ac37cc1aae74a0afb4d97@haskell.org> Message-ID: <068.be4e869e9286fa832d33588aa89aeed1@haskell.org> #7482: GHC.Event overwrites main IO managers hooks to RTS -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy AndreasVoellmy | Status: closed Type: bug | Milestone: 7.8.1 Priority: normal | Version: 7.4.1 Component: | Keywords: IO Manager, RTS libraries/base | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr, ekmett (added) Comment: Commit 2e86f4f609670a3d3ed05cedcf583326af670d9b: {{{ Author: Andreas Voellmy <> Date: Wed Dec 19 21:59:00 2012 -0500 Resolve issue #7482 by removing the ability to create a new event manager. A search of hackage showed that all packages that use this module (which is considered private to GHC) do not use the 'new' function. }}} Commit 8db9ad88a983f104d2a5c9706b1fd61250bd7aae: {{{ Author: Andreas Voellmy <> Date: Fri Dec 21 14:27:10 2012 -0500 Manager takes a flag that indicates whether it should de-register a file registration once it has received a callback. Previously, GHC.Event.Thread.threadWait calls unregister on the file in the callback. With this flag on, the manager now performs the deregistration so th }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 23:04:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 23:04:19 -0000 Subject: [GHC] #7482: GHC.Event overwrites main IO managers hooks to RTS In-Reply-To: <053.8265638cb53ac37cc1aae74a0afb4d97@haskell.org> References: <053.8265638cb53ac37cc1aae74a0afb4d97@haskell.org> Message-ID: <068.06c6e790022e65d2471605a10a459773@haskell.org> #7482: GHC.Event overwrites main IO managers hooks to RTS -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: 7.8.1 Priority: normal | Version: 7.4.1 Component: | Keywords: IO Manager, RTS libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: AndreasVoellmy => * status: closed => new * resolution: wontfix => Comment: Andreas, in commit 2e86f4 you removed `new` from GHC.Event's public interface, supposedly to workaround this bug. Later, in commit 8db9ad, you revert that change. Was that intentional? I'm also wondering about the functions `loop` and `shutdown`, which were exported in `base-4.6`, but aren't in `base-4.7` and higher. Was that intentional as well? In particular, I'm trying to figure out what to do about #5443, which uses all 3 of those functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 23:14:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 23:14:31 -0000 Subject: [GHC] #5443: Errors when shutting down the event manager loop In-Reply-To: <049.c83f389d37163cb8f5f3840f51a6024e@haskell.org> References: <049.c83f389d37163cb8f5f3840f51a6024e@haskell.org> Message-ID: <064.f74f2a7f91fa59ceba875786767130bf@haskell.org> #5443: Errors when shutting down the event manager loop -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown Comment: I can't tell at the moment whether this is still an issue or not. `base-4.7` does not export the functions `loop` and `shutdown`, see https://ghc.haskell.org/trac/ghc/ticket/7482#comment:8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 23:16:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 23:16:42 -0000 Subject: [GHC] #5495: simple program fails with -shared on mac In-Reply-To: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> References: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> Message-ID: <061.7528514e21a29606029813b602f91dcf@haskell.org> #5495: simple program fails with -shared on mac -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * difficulty: => Unknown Comment: Is this still a problem in 7.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 23:25:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 23:25:26 -0000 Subject: [GHC] #5416: Local modules and Template Haskell declaration splices In-Reply-To: <046.03ebb488ecfc90f0b742a5c96631cbcd@haskell.org> References: <046.03ebb488ecfc90f0b742a5c96631cbcd@haskell.org> Message-ID: <061.346025ab954ae4f7cb3b4c076a7e4de5@haskell.org> #5416: Local modules and Template Haskell declaration splices -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.2.1 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 23:34:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 23:34:09 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.ae36be86aea6f8354df2cd8b8769f763@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by ajp): Method 1 from the attached task may actually be made to work (at least on Linux). The key point is that we don't have to use the memory address that we happened to be given at startup. We can shift it to an aligned location using MREMAP, and simply include a mb of padding at the end to avoid trashing anything. Here's a modification of the code in the attached task that demostrates shifting the memory address with zero copies. {{{ ??[anders gurney] [~/devel/alignment] ??[139] cat test.S .section foo,"aw" .p2align 20 .global foo_start .global foo_end foo_start: .ascii "A" .fill 1048576 foo_end: .ascii "B" ??[anders gurney] [~/devel/alignment] ??[0] cat main.c #define _GNU_SOURCE #include #include extern char foo_start; extern char foo_end; size_t mb = 1024 * 1024; size_t round_to_mb(size_t x) { return (x + mb - 1) & ~(mb - 1); } size_t main(void) { printf("%c %c\n", foo_start, foo_end); // force libtest.so to be loaded printf("%p foo_start\n", &foo_start); printf("%p foo_end\n", &foo_end); printf("%d delta\n", &foo_end - &foo_start); void *next_mb_aligned_address = (void *) round_to_mb((size_t)&foo_start); printf("%p next mb aligned address\n", next_mb_aligned_address); void* new_address = mremap(&foo_start, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, next_mb_aligned_address); printf("%p %p // should be the same\n", new_address, next_mb_aligned_address); printf("%c // should be A\n", * (char *) new_address); printf("%c // should be B\n", foo_end); printf("and this should segfault\n"); printf("%c\n", foo_start); } ??[anders gurney] [~/devel/alignment] ??[0] gcc test.S -shared -o libtest.so -fPIC ??[anders gurney] [~/devel/alignment] ??[0] gcc -Wl,-R`pwd` -L. main.c -ltest -g -O0 -fPIC && ./a.out /nix/store/ycmsiznf2484vbjwmj57jdy2ncyrj7fj-binutils-2.23.1/bin/ld: warning: type and size of dynamic symbol `foo_start' are not defined /nix/store/ycmsiznf2484vbjwmj57jdy2ncyrj7fj-binutils-2.23.1/bin/ld: warning: type and size of dynamic symbol `foo_end' are not defined A B 0x7f8318c95000 foo_start 0x7f8318d95001 foo_end 1048577 delta 0x7f8318d00000 next mb aligned address 0x7f8318d00000 0x7f8318d00000 // should be the same A // should be A B // should be B and this should segfault zsh: segmentation fault ./a.out }}} Is there sonething fundamental that would prohibit this technique from working? It seems neater than the idea in #9706, as it - doesn't rely on overcommit - doesn't screw up accounting of VMA size - doesn't "use up" the trick of putting objects in arbitrary memory locations with MAP_FIXED. This could for example be used by an optimized application at the app level to use 48 bit pointers for a large skiplist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 23:35:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 23:35:48 -0000 Subject: [GHC] #5392: Warnings about impossible MPTCs would be nice In-Reply-To: <046.2a6e7255762b10f7d107224c7839fe0f@haskell.org> References: <046.2a6e7255762b10f7d107224c7839fe0f@haskell.org> Message-ID: <061.bfaafb19bca0b8ee0cfa80769f78f5b2@haskell.org> #5392: Warnings about impossible MPTCs would be nice -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.0.4 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: None/Unknown => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 23:41:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 23:41:43 -0000 Subject: [GHC] #5388: ghcilink003 and ghcilink006 fail on OSX In-Reply-To: <044.1dd6633d4dd57a6acc22a102b2ed7c4a@haskell.org> References: <044.1dd6633d4dd57a6acc22a102b2ed7c4a@haskell.org> Message-ID: <059.c29a3dad8d5cae25f7725bbbcf8d5dad@haskell.org> #5388: ghcilink003 and ghcilink006 fail on OSX -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.0.4 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: #9389 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => duplicate * related: => #9389 Comment: I'm combining all OS X testsuite failures in #9389, but these 2 particular tests don't seem to be failing anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 27 23:44:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Nov 2014 23:44:12 -0000 Subject: [GHC] #5387: ffi/should_run fptr02 fails on OS X amd64 In-Reply-To: <044.aa0b4d61e2abe55e2bd4d968a80124fc@haskell.org> References: <044.aa0b4d61e2abe55e2bd4d968a80124fc@haskell.org> Message-ID: <059.fe9c39398d9895a598d211e200463667@haskell.org> #5387: ffi/should_run fptr02 fails on OS X amd64 ---------------------------------------+---------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9389 Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => duplicate * related: => #9389 * milestone: 7.10.1 => Comment: I'm combining all OS X testsuite failures in #9389, but this particular test doesn't seem to be failing anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 00:03:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 00:03:48 -0000 Subject: [GHC] #5340: wrong warning on incomplete case analysis in conjunction with empty data declarations In-Reply-To: <046.3494d07f93db2655952ae9a32d6712ac@haskell.org> References: <046.3494d07f93db2655952ae9a32d6712ac@haskell.org> Message-ID: <061.ca164aefe5de41aea98e7027c2679552@haskell.org> #5340: wrong warning on incomplete case analysis in conjunction with empty data declarations -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 6.12.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Compiler (Type checker) * failure: None/Unknown => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 00:08:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 00:08:06 -0000 Subject: [GHC] #5333: Arrow command combinators and infixr cause the desugarer to fail In-Reply-To: <044.d282e017cea5d9685c27f48c7cf4a590@haskell.org> References: <044.d282e017cea5d9685c27f48c7cf4a590@haskell.org> Message-ID: <059.6fc1ec448f4feaa12282dfa26fcd6019@haskell.org> #5333: Arrow command combinators and infixr cause the desugarer to fail -------------------------------------+------------------------------------- Reporter: peteg | Owner: ross Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.0.3 (Parser) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): The testcase from the description compiles fine with HEAD (ghc-7.9.20141125). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 00:23:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 00:23:07 -0000 Subject: [GHC] #5320: check_overlap panic (7.1 regression) In-Reply-To: <057.bec42e7d5855255eb5d1162e43bb66ba@haskell.org> References: <057.bec42e7d5855255eb5d1162e43bb66ba@haskell.org> Message-ID: <072.58106c2dce394a202f4a89f6cdc2809b@haskell.org> #5320: check_overlap panic (7.1 regression) -------------------------------------+------------------------------------- Reporter: | Owner: simonpj mikhail.vorozhtsov | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Compile- | time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 00:42:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 00:42:07 -0000 Subject: [GHC] #5355: Link plugins against existing libHSghc In-Reply-To: <053.90d96b1c121110f57a47511594fdcf0f@haskell.org> References: <053.90d96b1c121110f57a47511594fdcf0f@haskell.org> Message-ID: <068.42f5a1a2e14fa29039f2146d167c6370@haskell.org> #5355: Link plugins against existing libHSghc -------------------------------------+------------------------------------- Reporter: | Owner: batterseapower | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.0.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5987 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * blockedby: 5292 => 5987 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 00:43:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 00:43:39 -0000 Subject: [GHC] #5292: libHSghc exports more symbols than Windows can handle In-Reply-To: <053.147874eecadbec2c18178c9ebc1910da@haskell.org> References: <053.147874eecadbec2c18178c9ebc1910da@haskell.org> Message-ID: <068.4d49dce9ec58c31c903d221ce2dad9af@haskell.org> #5292: libHSghc exports more symbols than Windows can handle -------------------------------------+------------------------------------- Reporter: | Owner: batterseapower | Status: closed Type: bug | Milestone: Priority: low | Version: 7.0.3 Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #5987 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => duplicate * related: => #5987 * milestone: 7.10.1 => Comment: The discussion has moved to #5987. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 01:01:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 01:01:56 -0000 Subject: [GHC] #5982: Incorrect dynamic library name in OSX In-Reply-To: <043.e9dbce1f8a84aa40b605402efe6d469c@haskell.org> References: <043.e9dbce1f8a84aa40b605402efe6d469c@haskell.org> Message-ID: <058.cb11b9f97c69705862bd266843b2b4ef@haskell.org> #5982: Incorrect dynamic library name in OSX ----------------------------------------+---------------------------------- Reporter: r0ml | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8266 Differential Revisions: | ----------------------------------------+---------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Actually closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 01:04:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 01:04:12 -0000 Subject: [GHC] #5289: Can't use ghci with a library linked against libstdc++ In-Reply-To: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> References: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> Message-ID: <057.3e625addb18a4fecad7a28c3fd50aaa7@haskell.org> #5289: Can't use ghci with a library linked against libstdc++ -------------------------------------+------------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Changes (by thomie): * os: Unknown/Multiple => Windows Comment: This is a Windows only bug now, if I understand correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 01:05:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 01:05:51 -0000 Subject: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations In-Reply-To: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> References: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> Message-ID: <061.e287930a47e3429bba00a5dedbc1cfc4@haskell.org> #5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 01:07:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 01:07:45 -0000 Subject: [GHC] #5841: seg fault in ghci but not ghc when using chart-gtk code In-Reply-To: <045.c0e839d25fa2feaad1e3187f69ad582f@haskell.org> References: <045.c0e839d25fa2feaad1e3187f69ad582f@haskell.org> Message-ID: <060.9273255afe4bb71445cd1d90ae375e2a@haskell.org> #5841: seg fault in ghci but not ghc when using chart-gtk code ---------------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5816 Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Actually closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 01:09:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 01:09:52 -0000 Subject: [GHC] #5777: core lint error with arrow notation and GADTs In-Reply-To: <045.ddc610a1c7376d3ac8e7cf64940c7d90@haskell.org> References: <045.ddc610a1c7376d3ac8e7cf64940c7d90@haskell.org> Message-ID: <060.f9217f3e546036322af5e8e6ac466cc1@haskell.org> #5777: core lint error with arrow notation and GADTs -------------------------------------+------------------------------------- Reporter: benmos | Owner: ross Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 (Type checker) | Keywords: arrows, GADTs Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * component: Compiler => Compiler (Type checker) Comment: Bug still present in HEAD (ghc-7.9.20141125). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 01:13:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 01:13:47 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.5f0fafec44a7680f8c128e4b94b2b983@haskell.org> #7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 01:39:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 01:39:11 -0000 Subject: [GHC] #5262: Compiling with -O makes some expressions too lazy and causes space leaks In-Reply-To: <051.404f1cdbe573b7b24ffc25fc24f60392@haskell.org> References: <051.404f1cdbe573b7b24ffc25fc24f60392@haskell.org> Message-ID: <066.e879d303fca94a78f083982c1dd8297a@haskell.org> #5262: Compiling with -O makes some expressions too lazy and causes space leaks -------------------------------------+------------------------------------- Reporter: | Owner: michal.palka | Status: new Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.1 Component: Compiler | Keywords: laziness, Resolution: | strictness, space leak Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: dfeuer (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 01:47:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 01:47:01 -0000 Subject: [GHC] #5266: Licensing requirements and copyright notices In-Reply-To: <047.3dbfbf3fe66178cd1b842c6c4b76070b@haskell.org> References: <047.3dbfbf3fe66178cd1b842c6c4b76070b@haskell.org> Message-ID: <062.a314d75a8861c13054e8a52f6a4c0d7f@haskell.org> #5266: Licensing requirements and copyright notices -------------------------------------+------------------------------------- Reporter: houeland | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: Component: None | Keywords: copyright Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: bernalex (added) * difficulty: => Unknown Comment: See also this mail from bernalex: https://www.haskell.org/pipermail/ghc- devs/2014-September/006235.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 01:55:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 01:55:13 -0000 Subject: [GHC] #5388: ghcilink003 and ghcilink006 fail on OSX In-Reply-To: <044.1dd6633d4dd57a6acc22a102b2ed7c4a@haskell.org> References: <044.1dd6633d4dd57a6acc22a102b2ed7c4a@haskell.org> Message-ID: <059.638431c43b664d3f882ba7242f74bad2@haskell.org> #5388: ghcilink003 and ghcilink006 fail on OSX -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.0.4 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: #9389 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 02:24:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 02:24:20 -0000 Subject: [GHC] #9843: Add flag to infer undefined for variables with only types Message-ID: <045.34f801ddff3b8de3af49cd3c76422063@haskell.org> #9843: Add flag to infer undefined for variables with only types -------------------------------------+------------------------------------- Reporter: tempay | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be convenient to be able to write only type declarations for some or all variables and have the compiler assume that the definitions of those variables are 'undefined'. For example: {{{#!hs functionOne :: x -> y functionTwo :: y -> z functionThree :: x -> y functionThree = functionOne . functionTwo }}} would be equivalent to {{{#!hs functionOne :: x -> y functionOne = undefined functionTwo :: y -> z functionTwo = undefined functionThree :: x -> y functionThree = functionOne . functionTwo }}} I feel this would make type-driven development significantly more convenient/clean. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 02:41:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 02:41:02 -0000 Subject: [GHC] #9843: Add flag to infer undefined for variables with only types In-Reply-To: <045.34f801ddff3b8de3af49cd3c76422063@haskell.org> References: <045.34f801ddff3b8de3af49cd3c76422063@haskell.org> Message-ID: <060.5693ad5d5c95784a1721fe52219929d3@haskell.org> #9843: Add flag to infer undefined for variables with only types -------------------------------------+------------------------------------- Reporter: tempay | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #393 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #393 Comment: Good idea, please subscribe to #393. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 03:10:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 03:10:24 -0000 Subject: [GHC] #5495: simple program fails with -shared on mac In-Reply-To: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> References: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> Message-ID: <061.fd13d48177bfd867d778a1cbf1f499c2@haskell.org> #5495: simple program fails with -shared on mac -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I think so ... {{{ > cat "main=putStrLn \"hi\"" > ghc --make foo.hs -shared -fforce-recomp [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... ld: illegal text reloc in '_c1Hl_info' to '_stg_ap_2_upd_info' for architecture x86_64 collect2: error: ld returned 1 exit status }}} a linker error seems to happen, though when GHC is configured to use clang, clang reports the error, whereas when using via GCC, its reported as a ld error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 03:28:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 03:28:43 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.16e0185d78a8e0c45c3d28023c8f0b6e@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm in support of this, too. But I won't have time to implement before the feature freeze... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 03:34:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 03:34:44 -0000 Subject: [GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types In-Reply-To: <050.b04515eaa5272881d87195907090dfe3@haskell.org> References: <050.b04515eaa5272881d87195907090dfe3@haskell.org> Message-ID: <065.8da4b78117b66f64fd4f36773ed5570b@haskell.org> #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): But, if you had local instances, then there wouldn't be just one, say, `Ord Int` out there. There would be the global one, and potentially many local ones. It now becomes very confused to try to use a `Set Int`, when the `Ord Int` instance might be changing. I'm not saying that local instances are Wrong, but that they require a fair amount of design work before we can begin to think about implementing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 03:53:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 03:53:10 -0000 Subject: [GHC] #9844: Bang pattern doesn't work on a newtype constructor Message-ID: <043.5612d473095f537e75e957abb6f3b481@haskell.org> #9844: Bang pattern doesn't work on a newtype constructor -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- According to the documentation, {{{f0}}} and {{{f1}}} in the following program should have the identical semantics: {{{#!hs {-# LANGUAGE BangPatterns #-} module Main where newtype N = N Int f0 :: N -> Int f0 n = case n of !(N _) -> 0 _ -> 1 f1 :: N -> Int f1 n = n `seq` case n of N _ -> 0 _ -> 1 main = do print $ f0 undefined print $ f1 undefined }}} However, ghc only compiles {{{f1}}} into a strict function: {{{ % ./bang-newtype 0 bang-newtype: Prelude.undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 05:48:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 05:48:55 -0000 Subject: [GHC] #5495: simple program fails with -shared on mac In-Reply-To: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> References: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> Message-ID: <061.1652a3952c6a411e3c3b0e3296eb37fb@haskell.org> #5495: simple program fails with -shared on mac -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not sure whether this is a bug at all. You need `-dynamic` also, to produce object files that can be linked dynamically. Granted, the way that `-shared` and `-dynamic` interact with make mode is, at best, not obvious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 08:15:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 08:15:14 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.6f0f5e2d62c6a82f4a96378e1ad153d6@haskell.org> #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by simonmar): @JeanPhilippeMoresmau I think you're probably running into #8935, which will be fixed in 7.8.4 and 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 08:20:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 08:20:10 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.ab6d84885a5196423b4eee8dbbad8529@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by simonmar): @ajp the problem is that this data is statically linked, not mmapped. If we move it somewhere else, all the references within it will be wrong. That's what method 2 was doing: relocating all the static closures elsewhere and fixing up all the pointers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 08:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 08:40:05 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.c140824155a2019624b964d2a4efd181@haskell.org> #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by JeanPhilippeMoresmau): @simonmar unfortunately my bug is still present in 7.8.4 rc1 (ghc-7.8.3.20141119). I'll create a new ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 08:46:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 08:46:19 -0000 Subject: [GHC] #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically Message-ID: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHC API | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: Related Tickets: 9480, 8935, 8376 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is code from the dynamic-cabal project, but I've distilled it into an easier test case. Basically you load a module that calls the Cabal configure function, and we try to call a function and get the result. This works fine if the executable is compiled with -dynamic, but segfaults (on Ubuntu at least) if the executable is static. I've had that behavior since 7.8.1 and I've seen several similar bugs come and be fixed, but the issue is still present in 7.8.4 rc1 (ghc-7.8.3.20141119) I attach the full project, with the cabal file, the Main.hs module that loads the DynamicCabalQuery.hs module -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 09:09:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 09:09:44 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.17e1563b2ad5dafef4880e50e960576e@haskell.org> #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by simonmar): Alas, I think the fix has not been committed yet. https://phabricator.haskell.org/D349 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 09:23:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 09:23:02 -0000 Subject: [GHC] #5443: Errors when shutting down the event manager loop In-Reply-To: <049.c83f389d37163cb8f5f3840f51a6024e@haskell.org> References: <049.c83f389d37163cb8f5f3840f51a6024e@haskell.org> Message-ID: <064.e69da8a516458dfefc693987b52cf434@haskell.org> #5443: Errors when shutting down the event manager loop -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by basvandijk): > I can't tell at the moment whether this is still an issue or not. In my usb library it's not a problem anymore since I'm now using the system event manager. So closing this ticket is fine with me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 09:58:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 09:58:09 -0000 Subject: [GHC] #5266: Licensing requirements and copyright notices In-Reply-To: <047.3dbfbf3fe66178cd1b842c6c4b76070b@haskell.org> References: <047.3dbfbf3fe66178cd1b842c6c4b76070b@haskell.org> Message-ID: <062.a9b170d380fba5e0df20b55faa6787cc@haskell.org> #5266: Licensing requirements and copyright notices -------------------------------------+------------------------------------- Reporter: houeland | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: Component: None | Keywords: copyright Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bernalex): * cc: hvr, thoughtpolice (added) Comment: Austin, Herbert & I briefly expressed related concerns in another thread: https://www.haskell.org/pipermail/ghc-devs/2014-October/006959.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 11:57:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 11:57:42 -0000 Subject: [GHC] #5495: simple program fails with -shared on mac In-Reply-To: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> References: <046.aeb51d939f07cb4da8bcfe42bb7b5f4a@haskell.org> Message-ID: <061.de69a6eb3a3d9ef4d0326e2ed0ec3412@haskell.org> #5495: simple program fails with -shared on mac -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 13:25:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 13:25:46 -0000 Subject: [GHC] #9844: Bang pattern doesn't work on a newtype constructor In-Reply-To: <043.5612d473095f537e75e957abb6f3b481@haskell.org> References: <043.5612d473095f537e75e957abb6f3b481@haskell.org> Message-ID: <058.16eda39d305c63df9022b0ebd5a13da4@haskell.org> #9844: Bang pattern doesn't work on a newtype constructor -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"227a566851f19f5a720c4a86fdb1ff99117325c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="227a566851f19f5a720c4a86fdb1ff99117325c6" Don't discard a bang on a newtype pattern (Trac #9844) We were wrongly simply dropping the bang, in tidy_bang_pat. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 13:27:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 13:27:23 -0000 Subject: [GHC] #9844: Bang pattern doesn't work on a newtype constructor In-Reply-To: <043.5612d473095f537e75e957abb6f3b481@haskell.org> References: <043.5612d473095f537e75e957abb6f3b481@haskell.org> Message-ID: <058.188522c1fa7323f774867d2a820905aa@haskell.org> #9844: Bang pattern doesn't work on a newtype constructor -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | deSugar/should_run/T9844 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => deSugar/should_run/T9844 * resolution: => fixed Comment: Excellent point, thank you. Now fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 14:04:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 14:04:57 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.2254cf54ad135c78ac403ce4236bf183@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"58dcd5c2e2a94643454296ea0bb109db96bd154f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="58dcd5c2e2a94643454296ea0bb109db96bd154f" Re-implement `testPrimeInteger` predicate (#9281) This also adds `testPrimeWord#` and `testPrimeBigNat` predicates. `testPrimeInteger` has been available since `integer-gmp-0.5.1` (added via f49735486533842cc84df70cafc8d565dffd75db). The `nextPrimeInteger` function is still missing though. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 14:22:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 14:22:28 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.83bd88671ef3df5820a8610038db75b5@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: gcampax Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D524 | -------------------------------------+------------------------------------- Comment (by simonmar): Anything less than 2% is probably noise, unless you can reproduce it consistently and/or there is some objective measurement such as number of instructions or memory reads using perf. There are other random effects that can cause small wobbles, even code placement by the linker or alignment effects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:01:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:01:44 -0000 Subject: [GHC] #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically In-Reply-To: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> References: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> Message-ID: <074.028700e82c638841a7cb2193067c9459@haskell.org> #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: infoneeded Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #9480, #8935, crash | #8376 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => infoneeded * related: 9480, 8935, 8376 => #9480, #8935, #8376 Comment: Phab:D349 fixes the issue on openSUSE. I attached a back port to ghc 7.8.4-RC1. Could you give it a try? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:03:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:03:42 -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.0c19d8d2f1bf99b6c82f900f2eb1a9fb@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.0.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 5877 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:09:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:09:15 -0000 Subject: [GHC] #5202: Docs on strictness info out of date In-Reply-To: <045.929872ac6b32e1b15e7e9335de1019e2@haskell.org> References: <045.929872ac6b32e1b15e7e9335de1019e2@haskell.org> Message-ID: <060.7b24b694240d89cae394fcd6a0af52ac@haskell.org> #5202: Docs on strictness info out of date -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.0.3 Documentation | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7546 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => duplicate * related: => #7546 * milestone: 7.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:21:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:21:19 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.ae5dd6a2760e66a8d8f512880d5e9ccb@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"8d7831108644584f710515b39b9fc97fbeca7a4c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8d7831108644584f710515b39b9fc97fbeca7a4c" Re-implement `nextPrimeInteger` predicate (#9281) This also adds `nextPrimeWord#` and `nextPrimeBigNat` predicates. `nextPrimeInteger` has been available since `integer-gmp-0.5.1` (added via f49735486533842cc84df70cafc8d565dffd75db). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:21:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:21:19 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.cac2ea6682c348cdade348ef1165d21b@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"2eecf348a62c47abd2f5de5f7eac5f7a3a779107/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2eecf348a62c47abd2f5de5f7eac5f7a3a779107" Re-activate `integerGmpInternals` test (#9281) The `integerGmpInternals` test was disabled in c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a as many of the primitives tested in that test weren't available yet w/ `integer-gmp2`. However, most operations have been reimplemented by now, with the exception of recipModInteger :: Integer -> Integer -> Integer gcdExtInteger :: Integer -> Integer -> (Integer, Integer) powModSecInteger :: Integer -> Integer -> Integer -> Integer powModInteger :: Integer -> Integer -> Integer -> Integer powInteger :: Integer -> Word -> Integer which are still missing, and will (time permitting) be reimplemented over time. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:26:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:26:13 -0000 Subject: [GHC] #5197: Support static linker semantics for archives and weak symbols In-Reply-To: <045.5d7250522a4c91dac0c31e2ca3e7d4e2@haskell.org> References: <045.5d7250522a4c91dac0c31e2ca3e7d4e2@haskell.org> Message-ID: <060.94ab9715ac2cad5ba46fa77a611be93b@haskell.org> #5197: Support static linker semantics for archives and weak symbols -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.0.3 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * difficulty: => Unknown * blockedby: 3658 => Comment: Still a problem with 7.8.3. {{{ $ uname -op x86_64 GNU/Linux $ cabal install llvm-general ... $ ghci -package llvm-general GHCi, version 7.8.3 ... Loading package llvm-general-3.4.4.1 ... linking ... Segmentation fault (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:34:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:34:58 -0000 Subject: [GHC] #5188: Runtime error when allocating lots of memory In-Reply-To: <046.23412d715d1f4494b90774a7c22b4d8d@haskell.org> References: <046.23412d715d1f4494b90774a7c22b4d8d@haskell.org> Message-ID: <061.7eebe332bd26cf99845ee1a10790b47f@haskell.org> #5188: Runtime error when allocating lots of memory -----------------------------------------+------------------------------ Reporter: knyblad | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------ Changes (by thomie): * cc: simonmar (added) * component: GHCi => Runtime System Comment: In commit 29ee739ec8937501171426ef845279ec307b18b8: {{{ Author: Austin Seipp <> Date: Thu Aug 29 17:30:16 2013 -0500 Revert "Check for integer overflow in osGetMBlocks" This reverts commit 48865521de6638240819b3979edbb3d33401dc8e. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:36:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:36:52 -0000 Subject: [GHC] #5158: Update .git-ignore in all the repos In-Reply-To: <044.8459ac04228d55825dbe5ef60f2287f0@haskell.org> References: <044.8459ac04228d55825dbe5ef60f2287f0@haskell.org> Message-ID: <059.c61e93d9eca4ddbccb0461ca656d879d@haskell.org> #5158: Update .git-ignore in all the repos -------------------------------------+------------------------------------- Reporter: igloo | Owner: pcapriotti Type: task | Status: closed Priority: low | Milestone: Component: Trac & Git | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * component: Compiler => Trac & Git * milestone: 7.10.1 => Comment: This is done every now and then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:41:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:41:02 -0000 Subject: [GHC] #5142: stub header files don't work with the MS C compiler In-Reply-To: <047.54b8421507beab9ed5b9b5ea133b33f5@haskell.org> References: <047.54b8421507beab9ed5b9b5ea133b33f5@haskell.org> Message-ID: <062.d8b6d7a30f606422bc807154f405cdbd@haskell.org> #5142: stub header files don't work with the MS C compiler -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:53:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:53:24 -0000 Subject: [GHC] #5075: CPR optimisation for sum types if only one constructor is used In-Reply-To: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> References: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> Message-ID: <068.4f21fc9fd53b7e5e46a0e48e3474bb1b@haskell.org> #5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------- Reporter: | Owner: simonpj batterseapower | Status: new Type: feature | Milestone: 7.10.1 request | Version: 7.0.3 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 16:58:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 16:58:25 -0000 Subject: [GHC] #5073: Add blockST for nested ST scopes In-Reply-To: <046.dde3302c1ed306a703cbded3f03bc8bc@haskell.org> References: <046.dde3302c1ed306a703cbded3f03bc8bc@haskell.org> Message-ID: <061.e985ac7f275cbeba435892d9ad1b0f61@haskell.org> #5073: Add blockST for nested ST scopes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.0.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 17:26:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 17:26:15 -0000 Subject: [GHC] #5051: Typechecker behaviour change In-Reply-To: <044.569620fef33303d8ae9785181226236d@haskell.org> References: <044.569620fef33303d8ae9785181226236d@haskell.org> Message-ID: <059.3d8dbe51079e9f949e664d4f9dfa1f5b@haskell.org> #5051: Typechecker behaviour change -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.0.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | typecheck/should_compile/T5051 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) * milestone: 7.10.1 => ? Comment: Replying to [comment:8 simonpj]: > As I say in comment:5, I think this is the right behaviour, so I don't propose to fix it at all. Setting milestone bottom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 17:37:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 17:37:21 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info In-Reply-To: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> References: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> Message-ID: <060.cdce8784ac322cd03c2285ae94ba2b1c@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"171101beca39befde191baff5027c417bcc709ee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="171101beca39befde191baff5027c417bcc709ee" Kind variables in RHS of an associated type instances should be bound on LHS This patche fixes Trac #9574. The previous Note [Renaming associated types] in RnTypes appears to me to be wrong; it confused class and instance declarations. I have: * Treated kind and type variables uniformly. Both must be bound on the LHS of an associated type instance. Eg instance C ('KProxy :: KProxy o) where type F 'KProxy = NatTr (Proxy :: o -> *) is illegal because 'o' is not bound on the LHS of the instance. * Moved the Note to RnSource and fixed it up This improves the error message from T7938. However it made the code in T6118 incorrect. We had: instance SingE (a :: Maybe k) where type Demote a = Maybe (Demote (Any :: k)) and that is now rejected, rightly I think. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 17:39:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 17:39:45 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info In-Reply-To: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> References: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> Message-ID: <060.f67a4ae044eaa060059723954c691a8a@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | polykinds/T9574 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T9574 * resolution: => fixed Comment: Thank you for reducing the test case so well. The problem is that the instance {{{ instance Funct ('KProxy :: KProxy o) where type Codomain 'KProxy = NatTr (Proxy :: o -> *) }}} should bind 'o' on the LHS of the type instance: {{{ instance Funct ('KProxy :: KProxy o) where type Codomain ('KProxy :: KProxy o) = NatTr (Proxy :: o -> *) }}} Otherwise there is nothing to connect the lhs and rhs. I've added this check. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 17:46:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 17:46:53 -0000 Subject: [GHC] #4960: Better inlining test in CoreUnfold In-Reply-To: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> References: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> Message-ID: <061.73a8f337137cd1151c7a6e73c6fa8eaa@haskell.org> #4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * type: bug => task * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 17:49:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 17:49:38 -0000 Subject: [GHC] #9846: GHC --make should also look for .hi, not only for .hs Message-ID: <045.3794dccbd8106489034cfa5bf262c765@haskell.org> #9846: GHC --make should also look for .hi, not only for .hs -------------------------------------+------------------------------------- Reporter: larsrh | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, `ghc --make` will only consider .hs source files from the include path. Example (assuming `Library` can't be resolved from the package database): `A.hs` {{{#!hs module A where import B import Library }}} `B.hs` {{{#!hs module B where }}} Compiling these files with `ghc --make -Idir A.hs B.hs` will succeed only if GHC finds a `Library.hs` file. In a thread on [https://www.haskell.org/pipermail/glasgow-haskell- users/2014-November/025476.html glasgow-haskell-users], Simon proposed relaxing this constraint; namely: In `--make` mode, when encountering an import `X`, GHC will try the following in order: 1. resolve the import from a package 2. search the include path for `X.hs` or `X.lhs` 3. search the include path for `X.hi` It already does 1 and 2, and this proposal would add 3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 17:57:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 17:57:25 -0000 Subject: [GHC] #5941: Add compilation stage plugins In-Reply-To: <044.b57cf00ec831ffd77a7e1faf72cc142b@haskell.org> References: <044.b57cf00ec831ffd77a7e1faf72cc142b@haskell.org> Message-ID: <059.c1686be0e72bbaca3ef11c3870791f49@haskell.org> #5941: Add compilation stage plugins -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): I find this a desirable feature, so I took a quick look. It seems that tcPlugin is currently focused on a pluggable constraint solver only: {{{#!hs data Plugin = Plugin { installCoreToDos :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo] -- ^ Modify the Core pipeline that will be used for compilation. -- This is called as the Core pipeline is built for every module -- being compiled, and plugins get the opportunity to modify the -- pipeline in a nondeterministic order. , tcPlugin :: [CommandLineOption] -> Maybe TcPlugin -- ^ An optional typechecker plugin, which may modify the -- behaviour of the constraint solver. } data TcPlugin = forall s. TcPlugin { tcPluginInit :: TcPluginM s -- ^ Initialize plugin, when entering type-checker. , tcPluginSolve :: s -> TcPluginSolver -- ^ Solve some constraints. -- TODO: WRITE MORE DETAILS ON HOW THIS WORKS. , tcPluginStop :: s -> TcPluginM () -- ^ Clean up after the plugin, when exiting the type-checker. } type TcPluginSolver = [Ct] -- given -> [Ct] -- derived -> [Ct] -- wanted -> TcPluginM TcPluginResult }}} At this point it seems that there are two main venues: 1. extend TcPlugin to add a hook for processing the final type-checked module (and widening the scope of {{{tcPluginInit}}} and {{{tcPluginSolve}}}), or 2. Add another plugin for AST hooks (ParsedModule, RenamedModule, and TypecheckedModule). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 17:59:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 17:59:13 -0000 Subject: [GHC] #4955: increase error message detail for module lookups failure due to hi references In-Reply-To: <045.9f69d0884b5c0d23dcd27cec8654a5ae@haskell.org> References: <045.9f69d0884b5c0d23dcd27cec8654a5ae@haskell.org> Message-ID: <060.01d5c30ef4dfe05b3dd380f13116dea9@haskell.org> #4955: increase error message detail for module lookups failure due to hi references -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.12.1 Component: Package | Keywords: system | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Package system * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 18:01:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 18:01:00 -0000 Subject: [GHC] #9846: GHC --make should also look for .hi, not only for .hs In-Reply-To: <045.3794dccbd8106489034cfa5bf262c765@haskell.org> References: <045.3794dccbd8106489034cfa5bf262c765@haskell.org> Message-ID: <060.e7a8501e097c5f3badaa66ef002ec908@haskell.org> #9846: GHC --make should also look for .hi, not only for .hs -------------------------------------+------------------------------------- Reporter: larsrh | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rodlogic): * cc: rodlogic (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 18:24:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 18:24:00 -0000 Subject: [GHC] #5941: Add compilation stage plugins In-Reply-To: <044.b57cf00ec831ffd77a7e1faf72cc142b@haskell.org> References: <044.b57cf00ec831ffd77a7e1faf72cc142b@haskell.org> Message-ID: <059.0a90aa3febbc7405e13ea7f7d20f3b11@haskell.org> #5941: Add compilation stage plugins -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): Now, from a user of this feature (or such feature), I would like to be able to do the following. Assuming I have, for example, two modules: {{{#!hs module A where import B main = sayHello "Joe" }}} {{{#!hs module B where sayHello :: String -> IO () sayHello = putStrLn }}} I would like to create a plugin, here named {{{DependenciesPlugin}}}, that is invoked with: {{{#!sh ghc -fplugin=DependenciesPlugin --make A.hs }}} This plugin would be called once to initialize itself, which in this case means creating a {{{A.dot}}} file: {{{ graph ModuleADependencies { }}} And once to terminate itself so that the {{{A.dot}}} file can be closed: {{{ } }}} In between the initialization and termination, the plugin would be called for each module to process the TypecheckedModule and generate a subgraph and the function dependencies: {{{ subgraph ModuleA { ModuleA.main [label="main"] } ModuleA.main -> ModuleB.sayHello subgraph ModuleB { ModuleB.sayHello [label="sayHello"] } }}} And command line options could be provided to tailor the DOT file generation (just module dependencies, only function dependencies, both, only dependencies from a specific functions, etc). Another option is to also take into account the packages these modules come from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 18:40:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 18:40:57 -0000 Subject: [GHC] #4938: Core2 CPU not detected correctly In-Reply-To: <045.5fd69e7a33d49880c3b3e207dc8b5f35@haskell.org> References: <045.5fd69e7a33d49880c3b3e207dc8b5f35@haskell.org> Message-ID: <060.2d69709ff2bde34c0dbebbe58b5136aa@haskell.org> #4938: Core2 CPU not detected correctly -------------------------------------+------------------------------------- Reporter: altaic | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * difficulty: => Unknown * os: Unknown/Multiple => MacOS X Comment: Is this still a problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 18:46:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 18:46:09 -0000 Subject: [GHC] #8323: explore ways to possibly use more tag bits in x86_64 pointers In-Reply-To: <045.7af99787c601e4e730a6e29b769c14e5@haskell.org> References: <045.7af99787c601e4e730a6e29b769c14e5@haskell.org> Message-ID: <060.9b5ae5f3eb6a07d6e5e4c02a8cd22027@haskell.org> #8323: explore ways to possibly use more tag bits in x86_64 pointers -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: #4937 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #4937 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 18:46:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 18:46:59 -0000 Subject: [GHC] #4937: Remove indirections caused by sum types, such as Maybe In-Reply-To: <044.b23df86df7a378aae0b2791d9692a9ef@haskell.org> References: <044.b23df86df7a378aae0b2791d9692a9ef@haskell.org> Message-ID: <059.d3d20e9f66e7b3488345e5a1e9116df1@haskell.org> #4937: Remove indirections caused by sum types, such as Maybe -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.0.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 19:33:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 19:33:34 -0000 Subject: [GHC] #4921: report ambiguous type variables more consistently In-Reply-To: <045.c5b1ea6508a19a0a431bf73213b97654@haskell.org> References: <045.c5b1ea6508a19a0a431bf73213b97654@haskell.org> Message-ID: <060.f6482a041879b19dfe46c8a03fea5dba@haskell.org> #4921: report ambiguous type variables more consistently -------------------------------------+------------------------------------- Reporter: Saizan | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown Comment: This seems fixed, pending a regression test. The error messages for `x` and `y` are no longer completely different. Ghc shows for `y`, since version 7.6.3: `The type variable ?b0? is ambiguous`. And since version 7.8.3 it doesn't show anymore: `Possible fix: add an instance declaration for (C Int b)`. Here is the full error message with HEAD: {{{ $ ghc-7.9.20141125 test.hs [1 of 1] Compiling Amb ( test.hs, test.o ) test.hs:10:9: No instance for (C a0 b1) arising from a use of ?f? The type variables ?a0?, ?b1? are ambiguous Relevant bindings include x :: a0 (bound at test.hs:10:1) Note: there is a potential instance available: instance C Int Char -- Defined at test.hs:7:10 In the first argument of ?fst?, namely ?f? In the expression: fst f In an equation for ?x?: x = fst f test.hs:11:9: No instance for (C Int b0) arising from a use of ?f? The type variable ?b0? is ambiguous Note: there is a potential instance available: instance C Int Char -- Defined at test.hs:7:10 In the first argument of ?fst?, namely ?f? In the expression: fst f :: Int In an equation for ?y?: y = fst f :: Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 19:53:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 19:53:22 -0000 Subject: [GHC] #4900: Consider usage files in the GHCi recompilation check (was: DEPENDS pragma) In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.9bfbcae1c35bf1d88aad852c4779d070@haskell.org> #4900: Consider usage files in the GHCi recompilation check -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: TH_Depends | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: Phab:D481 => Comment: Current status: there's a [https://ghc.haskell.org/trac/ghc/attachment/ticket/4900/0001-Consider- usage-files-in-the-GHCi-recompilation-check.4.patch patch]. See comment:67 why it's not ready yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 20:16:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 20:16:05 -0000 Subject: [GHC] #4896: Deriving Data does not work for attached code In-Reply-To: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> References: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> Message-ID: <059.203b5b07a84d47861dd4cb9bdd757d3c@haskell.org> #4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: This is the error message with HEAD (7.9.20141125) for the example from the description. {{{ Main.hs:17:66: Couldn't match type ?t'0 a0? with ?Bar? Expected type: Maybe (c (Bar (D a b))) Actual type: Maybe (c (t'0 a0 (D a b))) In the expression: gcast2 f In an equation for ?dataCast2?: dataCast2 f = gcast2 f When typechecking the code for ?dataCast2? in a derived instance for ?Data (Bar (D a b))?: To see the code I am typechecking, use -ddump-deriv }}} And the error message for mojojojo's example from comment:6 with HEAD (see also #5863): {{{ test.hs:5:40: Deriving Typeable is not allowed for family instances; derive Typeable for ?DF? alone In the data instance declaration for ?DF? test.hs:6:42: Deriving Typeable is not allowed for family instances; derive Typeable for ?DF? alone In the data instance declaration for ?DF? }}} Is there still a problem here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 20:45:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 20:45:26 -0000 Subject: [GHC] #4833: Finding the right loop breaker In-Reply-To: <046.867f982a678d81a76cbf7f56fd4d33fc@haskell.org> References: <046.867f982a678d81a76cbf7f56fd4d33fc@haskell.org> Message-ID: <061.43617eb02fe76a3c7d30c0d1c84c61d9@haskell.org> #4833: Finding the right loop breaker -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 20:53:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 20:53:22 -0000 Subject: [GHC] #4823: Loop strength reduction for array indexing In-Reply-To: <044.82dfe985922046910a65f46ae45b716a@haskell.org> References: <044.82dfe985922046910a65f46ae45b716a@haskell.org> Message-ID: <059.0ff28477ea33a1507305ce293337a1c1@haskell.org> #4823: Loop strength reduction for array indexing -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #7116 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * related: => #7116 * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 21:01:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 21:01:45 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.73e319056d9780c4d0bdae7bc59e32e3@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * difficulty: => Unknown Comment: mitar: please add an example to show the problem. What do you mean with "package is unusable?". Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 21:05:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 21:05:35 -0000 Subject: [GHC] #4520: startup code on Windows should use SetDllDirectory("") In-Reply-To: <045.de55fd062c967f225a99df4e00eb514e@haskell.org> References: <045.de55fd062c967f225a99df4e00eb514e@haskell.org> Message-ID: <060.da3929c6d2e079c68b8ad403956754d8@haskell.org> #4520: startup code on Windows should use SetDllDirectory("") -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * difficulty: => Unknown * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 28 23:17:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Nov 2014 23:17:16 -0000 Subject: [GHC] #9478: Partial type signatures In-Reply-To: <046.53a47ac5f73cf1b7df317af2585f061e@haskell.org> References: <046.53a47ac5f73cf1b7df317af2585f061e@haskell.org> Message-ID: <061.35b6645ac0608369c3d6165464033851@haskell.org> #9478: Partial type signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D168 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d831b6f41b3b89dc4a643069d5668c05a20f3c37/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d831b6f41b3b89dc4a643069d5668c05a20f3c37" Implement Partial Type Signatures Summary: Add support for Partial Type Signatures, i.e. holes in types, see: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures This requires an update to the Haddock submodule. Test Plan: validate Reviewers: austin, goldfire, simonpj Reviewed By: simonpj Subscribers: thomie, Iceland_jack, dominique.devriese, simonmar, carter, goldfire Differential Revision: https://phabricator.haskell.org/D168 GHC Trac Issues: #9478 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 00:03:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 00:03:29 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.71f697983e6be3954cdead6a4cc33d30@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mitar): See [https://stackoverflow.com/questions/13794168/haskell-cant-find- package here an example] of exactly what I am talking about here and how it confuses users. So user here has issues using Haskell program and module is said to not exist: `Could not find module 'Data.Vector'`. But then you can see such error: {{{ package vector-0.10.0.1-3450daae3d9f2092020075d05481123c is unusable due to missing or recursive dependencies: base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd primitive-0.5.0.1-15cdc8c11a54a78809b647af0c2975b3 }}} So instead of saying that that module is not found which make one think you just have to install it, something else should be said. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 00:21:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 00:21:45 -0000 Subject: [GHC] #4896: Deriving Data does not work for attached code In-Reply-To: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> References: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> Message-ID: <059.ba8b886e75194b20779eb3ad3f59a1b4@haskell.org> #4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mitar): I don't think that the question is what error message says, but that there should not be any errors and that GHC should know how to handle/compile this in the first place, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 10:43:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 10:43:44 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.41004c06b44a95b7c3188e9d8c961052@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5144 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): I think I like the `CE => CP` suggestion. Implementing it will be a bit tricky, because currently we typecheck pattern synonyms in two passes: * First we typecheck the pattern part, and build an internal representation `PatSyn`, which contains (among other things) the builder's `Id`, so it has to know its type. But currently that's not a problem, since the type is exactly known from the pattern part. * Then at a later point, the builder is typechecked against this type stored in `PatSyn`. So if we want to have any leeway in the builder type compared to the matcher type, we have to either typecheck the builder in the first stage as well, or not store its type in the `PatSyn`. To see why the first solution doesn't work, we need to look at the reason builders are typechecked in a separate pass: to support explicitly- bidirectional pattern synonyms where the builder refers to something which refers to the matcher, e.g. see `testsuite/tests/patsyn/should_run/bidir- explicit-scope.hs`: {{{ pattern First x <- x:_ where First x = foo [x, x, x] foo :: [a] -> [a] foo xs@(First x) = replicate (length xs + 1) x }}} However, we also can't omit the type of the builder from the `PatSyn` representation for the same reason: suppose `First` occured in the right- hand side of `foo`; how would we know what type to give it, if all we have at hand is the `PatSyn` for `First`? Maybe there's a way out of all this if the builder type is initialized to a fresh skolem tyvar which is filled in when the builder is typechecked; but someone more knowledgeable about the typechecker's internals will have to chime in on that. I'm worried that, at the very least, it would lead to horrible error messages when something goes wrong, since the use sites of a pattern synonym builder could now influence the typechecking of the definition of said builder. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 12:28:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 12:28:57 -0000 Subject: [GHC] #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 In-Reply-To: <048.595f7c7e08c33e6ee323b64468923777@haskell.org> References: <048.595f7c7e08c33e6ee323b64468923777@haskell.org> Message-ID: <063.c5c44536da065824148c8ce2255db9b8@haskell.org> #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 17:45:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 17:45:58 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.6f8aa3b70278d2d8802fa20dadd24b60@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"d0d4674281a80e4148a82f833948c2b4c3051eab/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d0d4674281a80e4148a82f833948c2b4c3051eab" Re-implement `powModInteger` (#9281) This also exposes the following type-specialised modular exponentiation variants of `powModInteger` useful for implementing a `powModNatural` operation. powModBigNat :: BigNat -> BigNat -> BigNat -> BigNat powModBigNatWord :: BigNat -> BigNat -> Word# -> Word# powModWord :: Word# -> Word# -> Word# -> Word# `powModInteger` has been available since `integer-gmp-0.5.1` (added via 4d516855241b70eb687d95e3c121428de885e83e) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 17:45:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 17:45:58 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.9cb289c3ae921c34a20bad55d074cac1@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"859680f6fe952ecbef3395fa4f299530d0f10c58/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="859680f6fe952ecbef3395fa4f299530d0f10c58" Implement `GHC.Natural.powModNatural` (#9818) This makes use of the `powMod*` primitives provided by `integer-gmp-1.0.0`. This is the `Natural`-version of the related `GHC.Integer.GMP.Internals.powModInteger` operation. The fallback implementation uses a square and multiply algorithm, compared to which the optimized GMP-based implementation needs much less allocations due to in-place mutation during the computation. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 17:49:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 17:49:03 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.67d7cd6525513b186fd8fab326466110@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"83c48438c800986c537d3cae682d53ee8ed326ed/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="83c48438c800986c537d3cae682d53ee8ed326ed" Re-implement `recipModInteger` (#9281) This also exposes the following two type-specialised modular exponentiation variants of `recipModInteger` useful for implementing a `recipModNatural` operation. recipModBigNat :: BigNat -> BigNat -> BigNat recipModWord :: Word# -> Word# -> Word# `recipModInteger` has been available since `integer-gmp-0.5.1` (added via 4d516855241b70eb687d95e3c121428de885e83e) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 17:51:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 17:51:01 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.852de64732fe92590b864c1a056be035@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"c0e0ca4d9d5ed47a5e9c88eeab9b538bc76a4eb5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c0e0ca4d9d5ed47a5e9c88eeab9b538bc76a4eb5" Reimplement `gcdExtInteger` (#9281) `gcdExtInteger` has been available since `integer-gmp-0.5.1` (added via 71e29584603cff38e7b83d3eb28b248362569d61) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 19:56:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 19:56:01 -0000 Subject: [GHC] #9757: Warn about derivable instances In-Reply-To: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> References: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> Message-ID: <060.63c6068d07aa8f4860fc5cf141964c0e@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Indeed, I'm certainly happy to discuss this on the HLint issue tracker. I think GHC warnings are generally general-purpose and clear issues (e.g. patterns are inexhaustive) while HLint ones can be more style-based and instance-specific (e.g. use notElem instead of not and elem). My guess is that it's probably impossible in any remotely general way to detect instances that would be better off done with generalised newtype deriving (and obviously actually impossible in the general case), but if anyone can come up with ideas/code I'd certainly consider it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 20:17:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 20:17:33 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.b0ea335cfcfe267c39c0a6fef56059e2@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------- Reporter: carter | Owner: sivteck Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by sivteck): * owner: => sivteck -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 20:24:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 20:24:41 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.94152524fff1b6173a57b40c4e9b2805@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------- Reporter: carter | Owner: sivteck Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D533| -------------------------------------+------------------------------------- Changes (by sivteck): * differential: => https://phabricator.haskell.org/D533 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 29 20:26:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Nov 2014 20:26:22 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.8e5693264d1ed93e0bdb23b163bf78e6@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------- Reporter: carter | Owner: sivteck Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D533 | -------------------------------------+------------------------------------- Changes (by sivteck): * differential: https://phabricator.haskell.org/D533 => Phab:D533 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 00:49:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 00:49:14 -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.c942994ed6ff0c8256634dc40efd4ee5@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: carlostome Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: T9778 | Blocking: | Differential Revisions: Phab:D534 | -------------------------------------+------------------------------------- Changes (by carlostome): * testcase: => T9778 * differential: => Phab:D534 Comment: I added this warning flag and updated the documentation according to it. The new flag is documented as follows: ---- -fwarn-unticked-promoted-constructors: Warn if a promoted data constructor is used without a tick preceding it's name. For example: {{{ data Nat = Succ Nat | Zero data Vec n s where Nil :: Vec Zero a Cons :: a -> Vec n a -> Vec (Succ n) a }}} This program will raise two warnings because Zero and Succ are not written as 'Zero and 'Succ. This warning is off by default. ---- If anybody thinks this can be explained better, all suggestions are welcomed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 09:01:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 09:01:45 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.68227b83a3e0bc0ffd9db09abe351986@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: Let's consider this accomplished for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 09:02:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 09:02:43 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.8d279ab7b644a3b3c379c3e6e7e9ea78@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 #9818 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Changes (by hvr): * related: #8647 => #8647 #9818 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 09:04:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 09:04:38 -0000 Subject: [GHC] #9818: Add `Natural` number type to `base` In-Reply-To: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> References: <042.8652fbefbb96a94879b1f06096e9b13e@haskell.org> Message-ID: <057.65853ee779af88185ba746f85c1d36e5@haskell.org> #9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Keywords: base natural Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #3650 #9281 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D473 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed * related: #3650 => #3650 #9281 Comment: This task is effectively done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 09:37:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 09:37:53 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.5c0738a4add15f09c090e3a339bf55f2@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"4c834fdddf4d44d12039da4d6a2c63a660975b95/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4c834fdddf4d44d12039da4d6a2c63a660975b95" Filter instance visibility based on set of visible orphans, fixes #2182. Summary: Amazingly, the fix for this very old bug is quite simple: when type- checking, maintain a set of "visible orphan modules" based on the orphans list of modules which we explicitly imported. When we import an instance and it is an orphan, we check if it is in the visible modules set, and if not, ignore it. A little bit of refactoring for when orphan-hood is calculated happens so that we always know if an instance is an orphan or not. For GHCi, we preinitialize the visible modules set based on the list of interactive imports which are active. Future work: Cache the visible orphan modules set for GHCi, rather than recomputing it every type-checking round. (But it's tricky what to do when you /remove/ a module: you need a data structure a little more complicated than just a set of modules.) Signed-off-by: Edward Z. Yang Test Plan: new tests and validate Reviewers: simonpj, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D488 GHC Trac Issues: #2182 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 10:02:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 10:02:38 -0000 Subject: [GHC] #9847: Remove "Difficulty" field from the Trac Message-ID: <048.2f318234beb94b756753871fe44a2045@haskell.org> #9847: Remove "Difficulty" field from the Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we recently discussed the [[Newcomers]] page on ghc-devs (this thread: https://www.haskell.org/pipermail/ghc- devs/2014-November/007297.html) we ended up with a conclusion that the "Difficulty" field is not very useful. Simon Marlow proposed that we should remove it: https://www.haskell.org/pipermail/ghc- devs/2014-November/007455.html I agree with Simon's opinion - we don't need Difficulty if we have Keywords. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 13:07:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 13:07:28 -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.e2efafb117cad896e7a782f611a145c6@haskell.org> #9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: carlostome Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: T9778 | Blocking: | Differential Revisions: Phab:D534 | -------------------------------------+------------------------------------- Changes (by carlostome): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 14:33:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 14:33:41 -0000 Subject: [GHC] #9005: Ship default bash completion file with ghc In-Reply-To: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> References: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> Message-ID: <059.3cf3a8dec5a3e4b543c626a2fd365644@haskell.org> #9005: Ship default bash completion file with ghc -------------------------------------+------------------------------------- Reporter: td123 | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.8.2 Component: None | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by kolmodin): * owner: => kolmodin Comment: I'm working on this. A bash completion will be added to GHC, and an accompanying README. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 16:10:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 16:10:46 -0000 Subject: [GHC] #7647: UNPACK polymorphic fields In-Reply-To: <045.8091f80cf766b683cf12520609e77aee@haskell.org> References: <045.8091f80cf766b683cf12520609e77aee@haskell.org> Message-ID: <060.92367b535a529c9c5772cad275ac4db3@haskell.org> #7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 3990 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bitonic): * cc: f@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 16:23:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 16:23:15 -0000 Subject: [GHC] #4470: Loop optimization: identical counters In-Reply-To: <048.cb41d64039b8fe820bdccdd94bb5c1a4@haskell.org> References: <048.cb41d64039b8fe820bdccdd94bb5c1a4@haskell.org> Message-ID: <063.05f20838e9a7e1c0afbac1db9d71438a@haskell.org> #4470: Loop optimization: identical counters -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: loop optimization Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 16:27:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 16:27:21 -0000 Subject: [GHC] #7647: UNPACK polymorphic fields In-Reply-To: <045.8091f80cf766b683cf12520609e77aee@haskell.org> References: <045.8091f80cf766b683cf12520609e77aee@haskell.org> Message-ID: <060.e2be0a1bb3429c2b2cd4a0eca7828885@haskell.org> #7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 3990 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bgamari): This morning I was thinking about how this might work. Would unpacking be restricted only to single-constructor polymorphic types? For instance, if I had, {{{ data Poly a = MkP !Bool {-# UNPACK #-} !a | MkP2 data Mango = MkMango {-# UNPACK #-} !(Poly Int) }}} Would I want to produce a representation that is the product of all of the unpacked variants? e.g.. {{{ data MangoRep = MangoRep1 !Bool !a | MangoRep2 }}} Or would we want to simply not unpack multi-constructor types? This seems to be how monomorphic types are currently handled, if I understand the code correctly. Moreover, how would a pattern match against an unpacked polymorphic type be lowered? Would we want to re-box `Poly` when pattern matching on `Mango`? Alternatively, we could somehow specialize functions on `Poly` to take the unboxed representation. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 16:46:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 16:46:07 -0000 Subject: [GHC] #4463: CORE notes break optimisation In-Reply-To: <041.fba7e0c53808b476cd12b364d160a8c0@haskell.org> References: <041.fba7e0c53808b476cd12b364d160a8c0@haskell.org> Message-ID: <056.a4d861d0491a024f7b2e8fc0116b95f5@haskell.org> #4463: CORE notes break optimisation -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: low | Milestone: ? Component: Compiler | Version: 7.1 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Support for `Core Notes` was added in 56b5a8b862d4eaeeaa941dd53e3d1009bdeadc0d, and seems to have gotten removed in 7bb0447df9a783c222c2a077e35e5013c7c68d91. I might be mistaken, but I think this ticket is no longer relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 16:59:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 16:59:37 -0000 Subject: [GHC] #4442: Add unaligned version of indexWordArray# In-Reply-To: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> References: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> Message-ID: <059.c82f5f52782335698c9dbde4347bf7e6@haskell.org> #4442: Add unaligned version of indexWordArray# -------------------------------------+------------------------------------- Reporter: tibbe | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug * component: Core Libraries => Compiler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 17:03:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 17:03:56 -0000 Subject: [GHC] #4470: Loop optimization: identical counters In-Reply-To: <048.cb41d64039b8fe820bdccdd94bb5c1a4@haskell.org> References: <048.cb41d64039b8fe820bdccdd94bb5c1a4@haskell.org> Message-ID: <063.079a3830dfa1a01b59ab188387ef9c31@haskell.org> #4470: Loop optimization: identical counters -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: loop optimization Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): this is (slightly?) related to series fusion as found in http://www.cse.unsw.edu.au/~amosr/papers/lippmeier2013flowfusion.pdf I think -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 17:07:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 17:07:48 -0000 Subject: [GHC] #9005: Ship default bash completion file with ghc In-Reply-To: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> References: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> Message-ID: <059.27e6385be89221def461be9bca3ecef6@haskell.org> #9005: Ship default bash completion file with ghc -------------------------------------+------------------------------------- Reporter: td123 | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.8.2 Component: None | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D536 | -------------------------------------+------------------------------------- Changes (by kolmodin): * differential: => Phab:D536 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 17:11:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 17:11:24 -0000 Subject: [GHC] #5406: Template Haskell: Reification of type family instances In-Reply-To: <046.93896fd35b75de09c5e9902faa94c744@haskell.org> References: <046.93896fd35b75de09c5e9902faa94c744@haskell.org> Message-ID: <061.67211532200a356ad3f6b241609f1a69@haskell.org> #5406: Template Haskell: Reification of type family instances -------------------------------------+------------------------------------- Reporter: reinerp | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.0.4 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | th/TH_reifyInstances | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => th/TH_reifyInstances * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 17:29:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 17:29:50 -0000 Subject: [GHC] #4470: Loop optimization: identical counters In-Reply-To: <048.cb41d64039b8fe820bdccdd94bb5c1a4@haskell.org> References: <048.cb41d64039b8fe820bdccdd94bb5c1a4@haskell.org> Message-ID: <063.9b908bd8cb8e9e15d9f0563d515c898b@haskell.org> #4470: Loop optimization: identical counters -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: loop optimization Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by choenerzs): It is (afaik) more than just slightly related. However, the (wanted) solutions are different. Flow fusion works within the limited context of repa by using a different intermediate system. Here, I'd like a more general solution -- since we can't express everything in terms of repa or even vector. On the other hand, I think it will be more complicated to get this done on the GHC side -- though the solution might be very worthwhile given the comments above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 18:01:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 18:01:29 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.ad37d891d4314cbc7138634e1995c6f2@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D337 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"6d47ab3ab3684c4245bdccd97d19db83887aae9c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6d47ab3ab3684c4245bdccd97d19db83887aae9c" Shorten long lines in DynFlags, add details to ghci usage guide. Summary: Shorten long lines in DynFlags. Describe --show-options in ghci usage guide. Reviewers: jstolarek, austin Reviewed By: jstolarek, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D532 GHC Trac Issues: #9259 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 18:01:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 18:01:29 -0000 Subject: [GHC] #9005: Ship default bash completion file with ghc In-Reply-To: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> References: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> Message-ID: <059.a8a8bdcfa09adb6ae8617b1e2677b223@haskell.org> #9005: Ship default bash completion file with ghc -------------------------------------+------------------------------------- Reporter: td123 | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.8.2 Component: None | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D536 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"643635ea1d779054e1bb3b1825cd7894c5748811/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="643635ea1d779054e1bb3b1825cd7894c5748811" Add bash completion and README Summary: The bash completion is simple but works both for ghc and ghci. The README explains to the user what they have to do to get it working (hopefully nothing). Test Plan: Follow the README, then enjoy the cli completion in your terminal! Reviewers: austin Subscribers: thomie, carter, jstolarek Differential Revision: https://phabricator.haskell.org/D536 GHC Trac Issues: #9005 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 18:01:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 18:01:29 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.7e2c814483c0096976cd5b75f4d45437@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"383733b9191a36e2d3f757700842dbc3855911d9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="383733b9191a36e2d3f757700842dbc3855911d9" Fix obscure problem with using the system linker (#8935) Summary: In a statically linked GHCi symbol `environ` resolves to NULL when called from a Haskell script. When resolving symbols in a Haskell script we need to search the executable program and its dependent (DT_NEEDED) shared libraries first and then search the loaded libraries. We want to be able to override functions in loaded libraries later. Libraries must be opened with local scope (RTLD_LOCAL) and not global. The latter adds all symbols to the executable program's symbols where they are then searched in loading order. We want reverse loading order. When libraries are loaded with local scope the dynamic linker cannot use symbols in that library when resolving the dependencies in another shared library. This changes the way files compiled to object code must be linked into temporary shared libraries. We link with the last temporary shared library created so far if it exists. Since each temporary shared library is linked to the previous temporary shared library the dynamic linker finds the latest definition of a symbol by following the dependency chain. See also Note [RTLD_LOCAL] for a summary of the problem and solution. Cherry-picked commit 2f8b4c Changed linker argument ordering On some ELF systems GNU ld (and others?) default to --as-needed and the order of libraries in the link matters. The last temporary shared library, must appear before all other libraries. Switching the position of extra_ld_inputs and lib_path_objs does that. Fixes #8935 and #9186 Reviewers: austin, hvr, rwbarton, simonmar Reviewed By: simonmar Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D349 GHC Trac Issues: #8935, #9186, #9480 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 18:01:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 18:01:30 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.ec8a276625801c53ed4083de913f205e@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"383733b9191a36e2d3f757700842dbc3855911d9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="383733b9191a36e2d3f757700842dbc3855911d9" Fix obscure problem with using the system linker (#8935) Summary: In a statically linked GHCi symbol `environ` resolves to NULL when called from a Haskell script. When resolving symbols in a Haskell script we need to search the executable program and its dependent (DT_NEEDED) shared libraries first and then search the loaded libraries. We want to be able to override functions in loaded libraries later. Libraries must be opened with local scope (RTLD_LOCAL) and not global. The latter adds all symbols to the executable program's symbols where they are then searched in loading order. We want reverse loading order. When libraries are loaded with local scope the dynamic linker cannot use symbols in that library when resolving the dependencies in another shared library. This changes the way files compiled to object code must be linked into temporary shared libraries. We link with the last temporary shared library created so far if it exists. Since each temporary shared library is linked to the previous temporary shared library the dynamic linker finds the latest definition of a symbol by following the dependency chain. See also Note [RTLD_LOCAL] for a summary of the problem and solution. Cherry-picked commit 2f8b4c Changed linker argument ordering On some ELF systems GNU ld (and others?) default to --as-needed and the order of libraries in the link matters. The last temporary shared library, must appear before all other libraries. Switching the position of extra_ld_inputs and lib_path_objs does that. Fixes #8935 and #9186 Reviewers: austin, hvr, rwbarton, simonmar Reviewed By: simonmar Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D349 GHC Trac Issues: #8935, #9186, #9480 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 18:01:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 18:01:30 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.e3048a47cf77fada9e6abef25bd5d211@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.8.1-rc2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Rocket Science Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9186, #9480 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"383733b9191a36e2d3f757700842dbc3855911d9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="383733b9191a36e2d3f757700842dbc3855911d9" Fix obscure problem with using the system linker (#8935) Summary: In a statically linked GHCi symbol `environ` resolves to NULL when called from a Haskell script. When resolving symbols in a Haskell script we need to search the executable program and its dependent (DT_NEEDED) shared libraries first and then search the loaded libraries. We want to be able to override functions in loaded libraries later. Libraries must be opened with local scope (RTLD_LOCAL) and not global. The latter adds all symbols to the executable program's symbols where they are then searched in loading order. We want reverse loading order. When libraries are loaded with local scope the dynamic linker cannot use symbols in that library when resolving the dependencies in another shared library. This changes the way files compiled to object code must be linked into temporary shared libraries. We link with the last temporary shared library created so far if it exists. Since each temporary shared library is linked to the previous temporary shared library the dynamic linker finds the latest definition of a symbol by following the dependency chain. See also Note [RTLD_LOCAL] for a summary of the problem and solution. Cherry-picked commit 2f8b4c Changed linker argument ordering On some ELF systems GNU ld (and others?) default to --as-needed and the order of libraries in the link matters. The last temporary shared library, must appear before all other libraries. Switching the position of extra_ld_inputs and lib_path_objs does that. Fixes #8935 and #9186 Reviewers: austin, hvr, rwbarton, simonmar Reviewed By: simonmar Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D349 GHC Trac Issues: #8935, #9186, #9480 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 18:06:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 18:06:56 -0000 Subject: [GHC] #4429: Ability to specify the namespace in mkName In-Reply-To: <046.5971bb4ac34a39579f0cc5517ce08c7b@haskell.org> References: <046.5971bb4ac34a39579f0cc5517ce08c7b@haskell.org> Message-ID: <061.606f3b53eb6219e58afa9779d3a40482@haskell.org> #4429: Ability to specify the namespace in mkName -------------------------------------+------------------------------------- Reporter: reinerp | Owner: reinerp Type: feature | Status: closed request | Milestone: Priority: low | Version: 6.12.3 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | th/TH_lookupName | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => th/TH_lookupName * resolution: => fixed * milestone: 7.10.1 => Comment: It looks like work for this ticket was finished a long time ago. Actual changes in comment:10, documentation and test in the following 2 commits: Commit d27c4541937219b60551a75662df805f0e6e54a1: {{{ Author: Simon Peyton Jones <> Date: Mon Jul 16 17:42:49 2012 +0100 Add documentation for Template Haskell functions Thanks to Reiner Pope for doing this }}} Commit dee226ccbaa091c9c8214f8764a6ebeaa0634587: {{{ Author: Reiner Pope <> Date: Wed Aug 24 09:41:09 2011 +1000 Test #4429, #5406 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 18:14:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 18:14:15 -0000 Subject: [GHC] #4428: Local functions lose their unfoldings In-Reply-To: <041.05f579c54cae7f6ea359ae3b76daabb5@haskell.org> References: <041.05f579c54cae7f6ea359ae3b76daabb5@haskell.org> Message-ID: <056.4f5d2c410eea8cfde406286157482c76@haskell.org> #4428: Local functions lose their unfoldings -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * difficulty: => Unknown Comment: What is the status of this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 18:31:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 18:31:58 -0000 Subject: [GHC] #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically In-Reply-To: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> References: <059.4340a519aad7bd56a35fa652e2b81e6f@haskell.org> Message-ID: <074.d69cea5ea942bcd0cb99e1eef44f0851@haskell.org> #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: infoneeded Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #9480, #8935, crash | #8376 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by JeanPhilippeMoresmau): As far as can tell, after building 7.8.4 rc1 with the attached patch, the problem has gone away and the code works! Thanks a million! Will that patch be part of the final release of 7.8.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 19:17:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 19:17:49 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.c7c8e284e7f9cf6650d2d25c4a2f3bf2@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------- Reporter: carter | Owner: sivteck Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D533 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6" compiler: fix trac issue #8815 Summary: This patch changes the error message as suggested in trac issue #8815 comments. Reviewers: jstolarek, austin Reviewed By: jstolarek, austin Subscribers: jstolarek, thomie, carter Differential Revision: https://phabricator.haskell.org/D533 GHC Trac Issues: #8815 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 19:23:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 19:23:36 -0000 Subject: [GHC] #4347: Bug in unification of polymorphic and not-yet-polymorphic type In-Reply-To: <044.ff04e8084e7aca9611c332ca30665a4b@haskell.org> References: <044.ff04e8084e7aca9611c332ca30665a4b@haskell.org> Message-ID: <059.a7242c14f80f019b8089e3fda097adc8@haskell.org> #4347: Bug in unification of polymorphic and not-yet-polymorphic type -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.1 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown Comment: With HEAD, the example from the description works (fails with 7.8.3). I don't know if this is incidental, or if anything got really fixed? {{{ $ ghci -XRankNTypes GHCi, version 7.9.20141125: ... Prelude> let f = id :: (forall a. a) -> (forall b. b) Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 19:32:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 19:32:36 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.87e209394a5ab00c77cf2bc78ac6a298@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------- Reporter: carter | Owner: sivteck Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D533 | -------------------------------------+------------------------------------- Changes (by sivteck): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 19:39:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 19:39:45 -0000 Subject: [GHC] #4329: GHC.Conc modifyTVar primitive In-Reply-To: <048.41d9c8120b92faf8b4aa586d8dc8e053@haskell.org> References: <048.41d9c8120b92faf8b4aa586d8dc8e053@haskell.org> Message-ID: <063.b68d227e828d55a9357abef9f79c9aca@haskell.org> #4329: GHC.Conc modifyTVar primitive -------------------------------------+------------------------------------- Reporter: dmbarbour | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.12.3 Component: Core | Keywords: TVar, STM, Libraries | modifyTVar, Concurrency Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * difficulty: => Unknown * component: Compiler => Core Libraries * owner: => ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 19:44:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 19:44:53 -0000 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> References: <044.c09df8f4b72158c8c14035187a5540c9@haskell.org> Message-ID: <059.1563b7f0b049f0a7826b067ca8e2d6eb@haskell.org> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 19:48:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 19:48:48 -0000 Subject: [GHC] #9848: List.all does not fuse Message-ID: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> #9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime Difficulty: Easy (less than 1 | performance bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- {{{ primes = 2:3:filter isPrime [5,7..] :: [Int] isPrime x = all (/= 0) . map (x `rem`) . takeWhile ((<= x) . (^2)) $ primes main = print . length . takeWhile (<= 2^24) $ primes }}} {{{ 12,133,812,164 bytes allocated in the heap 53,433,372 bytes copied during GC 14,235,488 bytes maximum residency (7 sample(s)) 1,110,916 bytes maximum slop 30 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 56357 colls, 0 par 0.094s 0.125s 0.0000s 0.0001s Gen 1 7 colls, 0 par 0.031s 0.034s 0.0049s 0.0154s INIT time 0.000s ( 0.000s elapsed) MUT time 8.094s ( 8.069s elapsed) GC time 0.125s ( 0.159s elapsed) EXIT time 0.000s ( 0.003s elapsed) Total time 8.219s ( 8.231s elapsed) %GC time 1.5% (1.9% elapsed) Alloc rate 1,499,158,259 bytes per MUT second Productivity 98.5% of total user, 98.3% of total elapsed }}} {{{ Rec { $sgo1_r2RE :: GHC.Prim.Int# -> [Int] -> Data.Monoid.All [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType ] $sgo1_r2RE = \ (sc_s2PS :: GHC.Prim.Int#) (sc1_s2PT :: [Int]) -> case sc_s2PS of _ [Occ=Dead] { __DEFAULT -> go_r2RF sc1_s2PT; 0 -> GHC.Types.False `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All) } go_r2RF :: [Int] -> Data.Monoid.All [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType ] go_r2RF = \ (ds_a1YK :: [Int]) -> case ds_a1YK of _ [Occ=Dead] { [] -> GHC.Types.True `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All); : y_a1YP ys_a1YQ -> case y_a1YP of _ [Occ=Dead] { GHC.Types.I# x_a1Tk -> case x_a1Tk of _ [Occ=Dead] { __DEFAULT -> go_r2RF ys_a1YQ; 0 -> GHC.Types.False `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All) } } } end Rec } lvl4_r2RG :: Int -> Data.Monoid.All [GblId, Arity=1, Str=DmdType] lvl4_r2RG = \ (x_aqY [OS=ProbOneShot] :: Int) -> case x_aqY of _ [Occ=Dead] { GHC.Types.I# y_a1Uc -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# 4 y_a1Uc) of _ [Occ=Dead] { False -> GHC.Types.True `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All); True -> $sgo1_r2RE (GHC.Prim.remInt# y_a1Uc 2) (letrec { go1_a1S5 [Occ=LoopBreaker] :: [Int] -> [Int] [LclId, Arity=1, Str=DmdType ] go1_a1S5 = \ (ds_a1S6 :: [Int]) -> case ds_a1S6 of _ [Occ=Dead] { [] -> GHC.Types.[] @ Int; : y1_X1T4 ys_X1T6 -> case y1_X1T4 of _ [Occ=Dead] { GHC.Types.I# x1_X1VM -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# (GHC.Prim.*# x1_X1VM x1_X1VM) y_a1Uc) of _ [Occ=Dead] { False -> GHC.Types.[] @ Int; True -> GHC.Types.: @ Int (case x1_X1VM of wild5_a1TE { __DEFAULT -> case GHC.Prim.remInt# y_a1Uc wild5_a1TE of wild6_a1TJ { __DEFAULT -> GHC.Types.I# wild6_a1TJ }; (-1) -> GHC.Real.$fIntegralInt1; 0 -> GHC.Real.divZeroError @ Int }) (go1_a1S5 ys_X1T6) } } }; } in go1_a1S5 Main.main3) } } }}} foldr, however, fuse just fine: {{{ primes = 2:3:filter isPrime [5,7..] :: [Int] isPrime x = foldr (&&) True . map (/= 0) . map (x `rem`) . takeWhile ((<= x) . (^2)) $ primes main = print . length . takeWhile (<= 2^24) $ primes }}} {{{ 365,770,752 bytes allocated in the heap 48,197,488 bytes copied during GC 13,031,232 bytes maximum residency (7 sample(s)) 1,570,524 bytes maximum slop 28 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 694 colls, 0 par 0.016s 0.029s 0.0000s 0.0005s Gen 1 7 colls, 0 par 0.031s 0.032s 0.0046s 0.0146s INIT time 0.000s ( 0.000s elapsed) MUT time 3.438s ( 3.439s elapsed) GC time 0.047s ( 0.062s elapsed) EXIT time 0.000s ( 0.003s elapsed) Total time 3.484s ( 3.504s elapsed) %GC time 1.3% (1.8% elapsed) Alloc rate 106,406,036 bytes per MUT second Productivity 98.7% of total user, 98.1% of total elapsed }}} {{{ lvl4_r2qr :: Int -> Bool [GblId, Arity=1, Str=DmdType] lvl4_r2qr = \ (x_aqW [OS=ProbOneShot] :: Int) -> case x_aqW of _ [Occ=Dead] { GHC.Types.I# y_a1tq -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# 4 y_a1tq) of _ [Occ=Dead] { False -> GHC.Types.True; True -> case GHC.Prim.remInt# y_a1tq 2 of _ [Occ=Dead] { __DEFAULT -> letrec { go_a1ud [Occ=LoopBreaker] :: [Int] -> Bool [LclId, Arity=1, Str=DmdType ] go_a1ud = \ (ds_a1ue :: [Int]) -> case ds_a1ue of _ [Occ=Dead] { [] -> GHC.Types.True; : y1_X1vf ys_X1vh -> case y1_X1vf of _ [Occ=Dead] { GHC.Types.I# x1_X1x9 -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# (GHC.Prim.*# x1_X1x9 x1_X1x9) y_a1tq) of _ [Occ=Dead] { False -> GHC.Types.True; True -> case x1_X1x9 of wild6_X1x3 { __DEFAULT -> case GHC.Prim.remInt# y_a1tq wild6_X1x3 of _ [Occ=Dead] { __DEFAULT -> go_a1ud ys_X1vh; 0 -> GHC.Types.False }; (-1) -> GHC.Types.False; 0 -> case GHC.Real.divZeroError of wild7_00 { } } } } }; } in go_a1ud Main.main3; 0 -> GHC.Types.False } } } }}} And List.all from ghc 7.8 base library does fuse, so this is regression. Windows 8.1 x64, ghc --info: {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","$topdir/../mingw/bin/gcc.exe") ,("C compiler flags"," -U__i686 -march=i686 -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","$topdir/../mingw/bin/gcc.exe") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","$topdir/../mingw/bin/ld.exe") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","$topdir/../mingw/bin/ar.exe") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","$topdir/touchy.exe") ,("dllwrap command","$topdir/../mingw/bin/dllwrap.exe") ,("windres command","$topdir/../mingw/bin/windres.exe") ,("libtool command","") ,("perl command","$topdir/../perl/perl.exe") ,("target os","OSMinGW32") ,("target arch","ArchX86") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.9.20141129") ,("Project Git commit id","447f592697fef04d1e19a2045ec707cfcd1eb59f") ,("Booter version","7.8.3") ,("Stage","2") ,("Build platform","i386-unknown-mingw32") ,("Host platform","i386-unknown-mingw32") ,("Target platform","i386-unknown-mingw32") ,("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 ") ,("Support dynamic-too","NO") ,("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","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","D:\\msys32\\usr\\local\\lib") ,("Global Package DB","D:\\msys32\\usr\\local\\lib\\package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 20:35:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 20:35:29 -0000 Subject: [GHC] #9757: Warn about derivable instances In-Reply-To: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> References: <045.a8d7646a67a5d965d67349d97ec3ca52@haskell.org> Message-ID: <060.29347f0c2bc5bd2024ca902064854683@haskell.org> #9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm not sure if this works with the way HLint is organized, but there is a decent way of detecting placing where GND can be used: take the Core produced from the instance definition of a newtype `N` (wrapping representation type `T`), strip out all coercions, and compare it against the Core for `T`'s instance. If each method in the instance for `N` is either a call to the method for `T`'s instance ''or'' symbol-for-symbol identical to `T`s instance, then GND is suitable. I think this algorithm would catch the common cases easily enough. But, like I said, I don't know how well looking at Core code matches with the way HLint normally goes about its business. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 21:17:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 21:17:39 -0000 Subject: [GHC] #4301: Optimisations give bad core for foldl' (flip seq) () In-Reply-To: <056.2dbd2c92c95b2418e58b472c1401290b@haskell.org> References: <056.2dbd2c92c95b2418e58b472c1401290b@haskell.org> Message-ID: <071.e5a6af590fbaf875fd22e8d76c8d5651@haskell.org> #4301: Optimisations give bad core for foldl' (flip seq) () -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: new Type: bug | Milestone: 7.10.1 Priority: low | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: dfeuer (added) * difficulty: => Unknown Comment: `foldl'` doesn't seem to get inlined with HEAD. I don't know if this ticket is still relevant. {{{ $ cat test.hs module Foo where import Data.List foo :: [a] -> () foo = foldl' (flip seq) () $ ghc-7.9.20141125 -ddump-simpl -dsuppress-all -fforce-recomp -O test.hs ... foo1 foo1 = \ @ a_aua x_auY y_auZ -> case y_auZ of _ { __DEFAULT -> x_auY } foo foo = \ @ a_aua -> foldl' (foo1) () }}} With 7.8.3: {{{ $ ghc-7.8.3 -ddump-simpl -dsuppress-all -fforce-recomp -O test.hs ... Rec { foo1 foo1 = \ @ a_avy w_sP6 -> case case w_sP6 of _ { [] -> (); : x_aOm xs_aOn -> case x_aOm of _ { __DEFAULT -> case foo1 xs_aOn of _ { (# #) -> () } } } of _ { () -> (##) } end Rec } foo foo = \ @ a_avy w_sPd -> case foo1 w_sPd of _ { (# #) -> () } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 21:26:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 21:26:04 -0000 Subject: [GHC] #4290: hClose002 test fails on Solaris/x86 due to bad expected output In-Reply-To: <046.f33011e5dee0b08536c12b8f9def3d93@haskell.org> References: <046.f33011e5dee0b08536c12b8f9def3d93@haskell.org> Message-ID: <061.c18131713aa6fc4f8b89f38a7970f815@haskell.org> #4290: hClose002 test fails on Solaris/x86 due to bad expected output -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: | Difficulty: Easy (less than 1 None/Unknown | hour) Test Case: hClose002 | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 21:37:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 21:37:07 -0000 Subject: [GHC] #4288: Poor -fspec-constr-count=n warning messages In-Reply-To: <044.c399244bac46e6eb32ab0a10e8263a7d@haskell.org> References: <044.c399244bac46e6eb32ab0a10e8263a7d@haskell.org> Message-ID: <059.2a9b6c9c781459d8064a461356a32178@haskell.org> #4288: Poor -fspec-constr-count=n warning messages -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.13 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown Old description: > The attached file, compiled with > {{{ > ghc -O2 -fspec-constr-count=5 -c q.hs > }}} > gives a number of messages like > {{{ > SpecConstr > Function `$j_X1BO{v} [lid]' > has one call pattern, but the limit is 0 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > SpecConstr > Function `$j_X1BR{v} [lid]' > has two call patterns, but the limit is 1 > Use -fspec-constr-count=n to set the bound > Use -dppr-debug to see specialisations > }}} > Note that the limit doesn't match the `spec-constr-count` we set. > > The "limit" given is `sc_count`, but `decreaseSpecCount` changes > `sc_count` from its default of `specConstrCount dflags`. However, if this > was fixed then we would get even stranger messages like > {{{ > has two call patterns, but the limit is 5 > }}} New description: The attached file, compiled with {{{ ghc -O2 -fspec-constr-count=5 -ddpr-debug -c q.hs }}} gives a number of messages like {{{ SpecConstr Function `$j_X1BO{v} [lid]' has one call pattern, but the limit is 0 Use -fspec-constr-count=n to set the bound Use -dppr-debug to see specialisations SpecConstr Function `$j_X1BR{v} [lid]' has two call patterns, but the limit is 1 Use -fspec-constr-count=n to set the bound Use -dppr-debug to see specialisations }}} Note that the limit doesn't match the `spec-constr-count` we set. The "limit" given is `sc_count`, but `decreaseSpecCount` changes `sc_count` from its default of `specConstrCount dflags`. However, if this was fixed then we would get even stranger messages like {{{ has two call patterns, but the limit is 5 }}} -- Comment: The messages are suppressed, unless you use `-dppr-debug`. See #5125. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 22:01:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 22:01:45 -0000 Subject: [GHC] #4222: Template Haskell lets you reify supposedly-abstract data types In-Reply-To: <046.e3ae8d54b8e418af2eef54ca9c93c353@haskell.org> References: <046.e3ae8d54b8e418af2eef54ca9c93c353@haskell.org> Message-ID: <061.83f40b9d3ca536590d46e55ba09aa351@haskell.org> #4222: Template Haskell lets you reify supposedly-abstract data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.12.3 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 23:43:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 23:43:01 -0000 Subject: [GHC] #4150: CPP+QuasiQuotes confuses compilation errors' line numbers In-Reply-To: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> References: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> Message-ID: <061.d76650b2afb9d6b7a4bef027e5873444@haskell.org> #4150: CPP+QuasiQuotes confuses compilation errors' line numbers -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.12.3 (Parser) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | quasiquotation/T4150 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => quasiquotation/T4150 * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 23:54:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 23:54:55 -0000 Subject: [GHC] #4121: Refactor the plumbing of CafInfo to make it more robust In-Reply-To: <045.e33af6968458760182e141457b350018@haskell.org> References: <045.e33af6968458760182e141457b350018@haskell.org> Message-ID: <060.e60fc2f541938f3dc8d3b1494902b54a@haskell.org> #4121: Refactor the plumbing of CafInfo to make it more robust -------------------------------------+------------------------------------- Reporter: dterei | Owner: Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * type: bug => task * failure: Building GHC failed => None/Unknown Comment: The "horrible hack" is still there. This ticket is currently not listed on [wiki:Status/SLPJ-Tickets]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 30 23:58:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Nov 2014 23:58:10 -0000 Subject: [GHC] #4105: ffi005 fails on OS X In-Reply-To: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> References: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> Message-ID: <059.3f270be4c3b34a7afd46adf82ee947e7@haskell.org> #4105: ffi005 fails on OS X -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 (FFI) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | ffi/should_run/ffi005 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: ffi005 => ffi/should_run/ffi005 * difficulty: => Unknown * component: Compiler => Compiler (FFI) -- Ticket URL: GHC The Glasgow Haskell Compiler